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 -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/bdba2266-6c94-4cc8-a02d-3916ab6d1bd5n%40googlegroups.com.
