Hello! On Thu, Jul 07, 2016 at 01:08:46PM -0700, Piotr Sikora wrote:
[...] > Furthermore, like you previously noted, official gRPC clients & server > are using HTTP/2, so there is absolutely no Google-agenda in pushing > HTTP/1.1 trailers, other than me wanting to add proper support for > trailers. So the question remains: are there any real-world use cases? May be someone will be able to provide some. Without real-world use cases I don't think this should be added, as in general trailers is quite external concept to how nginx works and also may have various security implications. > > Your patch forces use of chunked transfer encoding, and that's the > > point where I disagree. > > OK, that wasn't clear before. > > > The "TE: trailers" request header means > > that client is able to understand trailers, but it doesn't mean > > that chunked encoding must be used even if content length is > > known. Using chunked transfer encoding instead of Content-Length > > may or may not be justified by trailers, and this depends on a > > particular use case. > > Well, I think that if someone decides to add trailers in nginx.conf > (either via "add_trailer" or "proxy_pass_trailers" in the future), > then forcing chunked encoding and emitting those trailers is much > closer to the intent of the person that configured NGINX than silently > dropping them. > > If that's a blocker for you, then I can change this behavior, but I > think that most people would be quite surprised by explicitly > configured trailers that are silently dropped from the response. Silently dropping trailers is what anyway happens if the client doesn't support chunked encoding at all (e.g., uses HTTP/1.0). And this is also what happens in your patch if there is no "TE: trailers". I think that whether to drop Content-Length and switch to chunked encoding is highly use-case specific question. In some cases it may be appropriate, in some cases not, and in some cases one may want to add trailers even without "TE: trailers". So forcing chunked encoding probably should be configured separately. On the other hand, it's very hard to decide something given there are no real use cases known. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel