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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
