Code change:
Thanks NAME ready for re-review I think.
Oh, you proposed changing "handling" to "reporting": did you want to do that pervasively in this document?
Let's take that up separately.
Ready for merge I think.
I agree, but as this is substantive, let's run this by the working group.
As there is a draft deadline, I will open an issue for my niggle, and ask for forgiveness rather than permission.
It's not clear to me from RFC 7540 how an endpoint should behave upon receiving a frame that is erroneous in more than one way. For example, suppose a server receives the following frame when it has stream id 1 in half-closed (remote) state: According to §4.2, the frame "MUST be treated as a connection error" and the server "MUST send an error code of FRAMESIZEERROR" (because the length of 4 "is too small to contain mandatory frame data", namely the weight and header block fragment fields); According to §5.1, the server "MUST respond with a stream error (Section 5.4.2) of type STREAMCLOSED" (because a frame "other than WINDOWUPDATE, PRIORITY, or RSTSTREAM" was received for a stream that is in "half-closed (remote)" state); and According to §5.3.1, the server "MUST treat this as a stream error (Section 5.4.2) of type PROTOCOLERROR" (because "a stream cannot depend on itself"). That is to say, according to the RFC, the server MUST (at very least) respond to this frame with one GOAWAY frame and two RSTSTREAM frames. However, sending all these frames would violate other requirements: According to §5.4.1, "after sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection". This obviously prevents other frames from being sent. According to §5.1, sending a RSTSTREAM transitions the stream to closed state, in which "an endpoint MUST NOT send frames other than PRIORITY". This prevents any further RSTSTREAM frames from being sent for the same stream. In this particular case, it seems reasonable to me that the frame size error should halt further processing of the frame such that neither of the stream errors are even detected: after all, an incorrect frame size may indicate corruption (in which case the rest of the frame's data must also be suspect). But this is neither clear from the spec nor might other cases be so clear cut. I see three possibilities, with a reasonably strong leaning toward the first: Clarify that further processing of frames SHOULD (or MUST?) be halted upon encountering an error (I suspect this is what most implementations currently do, irrespective that the RFC says they "MUST" behave otherwise?). But then the order of processing becomes significant: is it right that this should be left as an implementation detail, or should it be specified? After all, the above frame might trigger a STREAMCLOSED stream error from one server and a FRAMESIZEERROR connection error from another, with very different consequences: how might these differences impact intermediaries, caching and retries? Better I think for the order to be specified. Define a precedence to errors, and mandate that that with highest precedence be sent (for example, connection errors might have higher precedence than stream errors). But then endpoints must continue processing frames they know to be erroneous simply to discover whether any higher precedence errors also exist (at least until an error of the highest possible precedence is encountered). Permit (require?) all errors arising from a single frame to be transmitted irrespective of any other errors the frame may also have triggered. Again, endpoints would then continue processing frames that they know to be erroneous—but the peer would then be fully informed of all problems in order that it is better able to recover.
I think the simplest explanation is that connection errors are those that suggest there's no way to (safely) continue attempting to parse anything. I suspect most implementations would find that this frame is not long enough to actually be a HEADERS frame and not attempt to parse it as a frame it cannot actually be. Thus, while a given implementation could possibly discover one of the stream errors first (thereby sending a RST_STREAM), once you discover the connection error, you're sending the GOAWAY and throwing the connection state away. The logical implementation is likely to find the connection error immediately and not read far enough to find the others.
I agree, but this is not specified. Is it okay to leave as an implementation detail, even if most implementations will do the "logical thing"? Also this was just one example of a frame with multiple errors... others may not be so straightforward.
The question we should ask is: Is there any behavior that would change that would cause it to not interoperate here? I suspect that, regardless of how one interprets this, processing must stop, and the client may or may not receive an error, thanks to the vagaries of packet-loss. If this requires any clarification, I'd pick the path of asserting that any connection error stops any other processing.
Actually I also found error handling quite tricky to do, especially regarding when and what to send in GOAWAY frames. One really needs to think in terms of error severity to implement a form of funnel so that more severe errors can still be emitted after less serious ones. One example that quickly comes to mind is that we can send a GOAWAY frame to indicate a graceful shutdown of a connection yet this one is not an error and may be followed by other GOAWAY reporting protocol violations. I also faced an annoying situation related to TCP where you can't send a GOAWAY frame due to a buffer full situation, and closing after this causes a reset to be emitted due to pending incoming data. So we actually have to enter an input drain state in error situations, which further adds to the implementation complexity.
QUIC has that I think h2 would benefit from.
See for some proposed text to address this. We probably need to workshop it a bit.
Thanks!

Related discussion:
text: A list of error codes is included in ErrorCodes. <ins> It is possible that an endpoint will encounter frames that would cause multiple errors.  Implementations MAY discover multiple errors during processing, but they SHOULD report at most one stream and one connection error as a result. The first stream error reported for a given stream prevents any other errors on that stream from being reported.  In comparison, the protocol permits multiple GOAWAY frames, though an endpoint SHOULD report just one type of connection error unless an error is encountered during graceful shutdown.  If this occurs, an endpoint MAY send an additional GOAWAY frame with the new error code, in addition to any prior GOAWAY that contained NO_ERROR. If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection error, that error MUST be reported. </ins> 5.4.1. A connection error is any error that prevents further processing of