Open franfastly opened 4 months ago
I remember that conversation. I think that's probably generally fine.
cc @acfoltzer @nox @Noah-Kennedy, thoughts?
@seanmonstar I've been working with @franfastly on this investigation and an internal patch we've been cooking up to address the issue. I think overall I would prefer that h2
just return HEADERS+END_STREAM
in these cases where the framing of h2 itself is not at risk, but at the moment that behavior would break h2spec tests. Pending movement on that issue, Fran and I believe this is the best solution.
Issue
h2
returnsRST_STREAM
frames with thePROTOCOL_ERROR
bit set as a response to many types of errors in client requests. Many of those cases, when handled by an HTTP/1 server such as the one used inhyper
, would result in an HTTP 400 Bad Request response returned to the client rather than a TCP reset (the HTTP/1 equivalent of aRST_STREAM
). As a consequence, a client will observe differences in behaviour between HTTP/1 and HTTP/2: a malformed request will result in a 400 response when HTTP/1 is used whereas the same request will result in a reset stream withh2
.Proposal
There was a conversation in the mailing list of the IETF-HTTP-WG about whether a server can send a response to malformed requests instead of treating them as a stream error. From Steffan Eising's last response to that thread:
Although there was no consensus about specifying a single correct behaviour, I think it was clear that a 400 response was acceptable.
I could create a PR to make
h2
reply aHEADERS
+400
+END_STREAM
frame followed by aRST_STREAM
+PROTOCOL_ERROR
frame to all themalformed!()
macro invocations in https://github.com/hyperium/h2/blob/0077d3dcb4266c18d2b569f0257caff24778335b/src/server.rs#L1506