On Thu, Apr 28, 2022 at 10:03 PM Samuel Williams < [email protected]> 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." -- 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/CA%2B4M1oN824fx%3D5kRzQmGXtC4mPhcEoXd5H5M2p3iNT_VTDgK2w%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
