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@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@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel