Issue

h2 returns RST_STREAM frames with the PROTOCOL_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 in hyper, would result in an HTTP 400 Bad Request response returned to the client rather than a TCP reset (the HTTP/1 equivalent of a RST_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 with h2.

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:

• Sending a HTTP response is preferable, since this gives much better error reporting on the client side.
• Violations of HTTP/2 framing layer should error on the h2 layer. Basically, the server no longer trusts the client.
• Sending a RESPONSE with subsequent RST is a good pattern

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 a HEADERS+400+END_STREAM frame followed by a RST_STREAM+PROTOCOL_ERROR frame to all the malformed!() macro invocations in