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