Hey Maxim,

> 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
receive trailers.

> 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?

Best regards,
Piotr Sikora

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