Is gRPC actually compatible with HTTP semantics?

[Samuel Williams]

Hello, I'm the maintainer of an HTTP client/server covering HTTP/1 & 2.

I've been asked to change some of the internal checks (errors) when trailers are given which didn't exist in the `trailer` header.

Looking at the RFCs, I'm trying to figure out if this is a reasonable interpretation of the HTTP semantics.

HTTP/1 says "SHOULD" have `te: trailers` in the client to server request headers, `trailer: name1, name2, ... nameN` in the response headers and `name1, name2, ... nameN` after a chunked body.

I don't see as much detail in the relevant RFCs for HTTP/2, so maybe that means it's not needed. But it seems like that's the correct semantics for HTTP, at least for HTTP/2, `te: trailers` can be assumed since it's always supported, but `trailer: name1, name2, ..., nameN` "SHOULD" still be provided in the response headers, from my interpretation of the various RFCs.

To me, that's enough of a problem that gRPC can't work within a code base which strictly follows HTTP RFCs. Of course, the HTTP/2 protocol is still the same... just the semantics of the requests and responses is a bit different.

I would really appreciate any insight you might have regarding how this should be handled as someone who wants to implement a compliant HTTP1/2 client & server interface, and whether gRPC is compliant with HTTP as a semantic rather than just HTTP/2 the protocol/framing format.

Thanks,

Samuel

[Eric Anderson]

On Thu, Apr 28, 2022 at 10:03 PM Samuel Williams <space.ship...@gmail.com> wrote:

Hello, I'm the maintainer of an HTTP client/server covering HTTP/1 & 2.

I assume this is related to https://github.com/socketry/async-http/pull/92 . I saw the thread, but it seemed to resolve reasonably correctly, so I decided I didn't need to speak up.

HTTP/1 says "SHOULD" have `te: trailers` in the client to server request headers, `trailer: name1, name2, ... nameN` in the response headers and `name1, name2, ... nameN` after a chunked body.

Right, it is a helpful aid to the client, but isn't mandatory. In gRPC there have been some implementations where the server responds with trailer header due to specific APIs (e.g., the Go HTTP server API). That is "okay" from gRPC's perspective but not mandatory.

I don't see as much detail in the relevant RFCs for HTTP/2, so maybe that means it's not needed.

HTTP/2 doesn't change the semantics here at all.

I would really appreciate any insight you might have regarding how this should be handled as someone who wants to implement a compliant HTTP1/2 client & server interface, and whether gRPC is compliant with HTTP as a semantic rather than just HTTP/2 the protocol/framing format.

The RFC has the SHOULD for the sender but nothing for the receiver. I see few allowances afforded to the receiver other than accepting all the trailers or ignoring all the trailers. There's nothing about stripping out trailers that are lacking from the Trailer header, for example. Failing definitely seems inappropriate.

The Trailer header just seems like an optimization. It is helpful, but not mandatory. "Welcome to HTTP."