[PATCH 1 of 2] HTTP: add support for trailers in HTTP responses
piotrsikora at google.com
Thu Jul 7 20:08:46 UTC 2016
> 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
> 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
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.
More information about the nginx-devel