Hey Maxim,

> What's the goal? Any real-world use for this?

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