[PATCH 1 of 2] HTTP: add support for trailers in HTTP responses

shuxinyang shuxinyang.oss at gmail.com
Mon Jun 27 17:04:05 UTC 2016


Hi, Piotr:

    I'm wondering why not just change the ngx_http_chunked_filter_module.c?
or add a module inserted right after the chunked-filter-module?

Shuxin

On 06/27/2016 07:37 AM, Piotr Sikora wrote:
> Hey Maxim,
>
>> What's the goal?  Any real-world use for this?
>
>
>
> On 06/27/2016 06:45 AM, Maxim Dounin wrote:
>> Hello!
>>
>> On Sun, Jun 26, 2016 at 04:13:15PM -0700, Piotr Sikora wrote:
>>
>>> # HG changeset patch
>>> # User Piotr Sikora <piotrsikora at google.com>
>>> # Date 1466735480 25200
>>> #      Thu Jun 23 19:31:20 2016 -0700
>>> # Node ID a96187a9806536ab2a8bf3fa7f7b659cf5d3ff13
>>> # Parent  6f69e3c0f780e29bca752fc1f938f4a459a1ec59
>>> HTTP: add support for trailers in HTTP responses.
>>>
>>> Example:
>>>
>>>     ngx_table_elt_t  *h;
>>>
>>>     h = ngx_list_push(&r->headers_out.trailers);
>>>     if (h == NULL) {
>>>         return NGX_ERROR;
>>>     }
>>>
>>>     ngx_str_set(&h->key, "Fun");
>>>     ngx_str_set(&h->value, "with trailers");
> For us? gRPC, which uses HTTP/2 and/or HTTP/1.1 with trailers as a
> transport protocol.
>
>> As far as I understand the patch, this will cause chunked encoding
>> to be used for all responses to a client which supports trailers.
>> This certainly looks like a bad idea.
> It will force chunked encoding in responses to HTTP/1.1 requests with
> "TE: trailers", i.e. only when HTTP/1.1 client explicitly asked for
> trailers.
>
> Since, at this point (i.e. while processing headers), we don't know
> whether there will be any trailers after response body (because proxy*
> and/or 3rd-party modules might add them later), forcing chunked
> encoding for all clients that asked for trailers is the most
> reasonable thing we can do.
>
> Alternatively, we could add an indicator (i.e. r->trailers_emit) that
> proxy* and/or 3rd-party modules could set in case they expect to emit
> trailers, but to be honest, I feel that it would be just set to 1
> (unless we want to whitelist which trailers are passed down from
> upstream).
>
> * I'm going to work on proxy support for trailers at some point in
> future, if this gets merged.
>
> Best regards,
> Piotr Sikora
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel



More information about the nginx-devel mailing list