Code change:
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

Related discussion:
text: 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.