Hey Maxim, > And these 3 people are the only people asking/commenting about > trailers during the whole nginx history, AFAIR. And none of them > provided any real-world use for trailers.
That's true... Wesley, Shuxin, would you mind sharing your use cases? > On the other hand, your > motivation is quite clear, it's about Google pushing it's own > library, nothing more. I disagree. There is nothing gRPC-specific about trailers, the protocol is just layered on top of HTTP standard. 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. > 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. Best regard, Piotr Sikora _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
