[PATCH 1 of 2] HTTP: add support for trailers in HTTP responses
piotrsikora at google.com
Mon Jun 27 19:03:56 UTC 2016
> 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?
Official clients & servers support only HTTP/2, but gRPC protocol can
be layered on top of HTTP/1.1 with trailers, so it's up to the
implementation to offer gRPC-over-HTTP/1.1 support.
As for HTTP/2 trailers, the code I submitted is already used to send
gRPC-over-HTTP/2, so it's quite real-world use case.
> 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.
In theory, you're right...
In practice, I'm not aware of any generic-purpose client sending "TE:
trailers" header (i.e. browsers don't send it, even though at least
some support trailers), and it's used only by clients that want to
> 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.
NGINX can add them with "add_trailer", which works even with HTTP/1.0
backends... But point taken.
Would adding r->trailers_emit (or r->expect_trailers, whichever you
prefer) make you happy?
More information about the nginx-devel