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
