Hello!

On Mon, Jun 27, 2016 at 07:37:31AM -0700, Piotr Sikora wrote:

> > What's the goal? Any real-world use for this?
>
> For us? gRPC, which uses HTTP/2 and/or HTTP/1.1 with trailers as a
> transport protocol.

Last time I checked gRPC wasn't able to talk HTTP/1.1, and
therefore wasn't able to work with nginx at all. So no real-world
use for now, right?

> > As far as I understand the patch, this will cause chunked encoding
> > to be used for all responses to a client which supports trailers.
> > This certainly looks like a bad idea.
>
> It will force chunked encoding in responses to HTTP/1.1 requests with
> "TE: trailers", i.e. only when HTTP/1.1 client explicitly asked for
> trailers.

I disagree here. "TE: trailers" doesn't mean that client asked
for trailers, it instead indicates that client supports trailers.
Quoting RFC 7230:

The "TE" header field in a request indicates what transfer codings,
besides chunked, the client is willing to accept in response, and
whether or not the client is willing to accept trailer fields in a
chunked transfer coding.

Using chunked for all clients who send "TE: trailers" looks like a
bad idea for me, it will hurt at least some real-world clients.

> Since, at this point (i.e. while processing headers), we don't know
> whether there will be any trailers after response body (because proxy*
> and/or 3rd-party modules might add them later), forcing chunked
> encoding for all clients that asked for trailers is the most
> reasonable thing we can do.
>
> Alternatively, we could add an indicator (i.e. r->trailers_emit) that
> proxy* and/or 3rd-party modules could set in case they expect to emit
> trailers, but to be honest, I feel that it would be just set to 1
> (unless we want to whitelist which trailers are passed down from
> upstream).

At least in case of proxy, trailers are expected to appear if and
only if protocol used to talk to the upstream server supports
them. That is, it's only expected to happen when talking to a
backend via HTTP/1.1, and the response uses chunked encoding.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel