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