Re: [quicwg/base-drafts] Use the FRAME_ENCODING_ERROR for errors in frame encoding (#3042)

[Kazuho Oku <[e-mail]>]

@marten-seemann I think you are conflating two different issues. #2524 is an issue about the amount of data buffered, while this issue is about the maximum offset of data an endpoint can ultimately represent.

Let me explain why "MUST respond with a FRAME_ENCODING_ERROR" for a CRYPTO stream is a problem.

The reason we have allowed the use of FLOW_CONTROL_ERROR for STREAM frames is because that is an error that can be caught by the stream-level receive buffer (and it's logic), rather than the frame decoder.

Stating that the error code MUST be FRAME_ENCODING_ERROR in this particular case goes against that agreement.

That logic that we used for STREAM frames can be equally applied to CRYPTO streams. The error code can either be CRYPTO_BUFFER_EXCEEDED or FLOW_CONTROL_ERROR. I don't mind either. But requiring FRAME_ENCODING_ERROR is different, because it could require the stream-level logic to respond either with a stream-level error code (CRYPTO_BUFFER_EXCEEDED or FLOW_CONTROL_ERROR) and frame-level error code (FRAME_DECODING_ERROR) based on the input. As can be seen, this requirement to distinguish between the two cases is the same as the one we argue for the STREAM frame case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3042#issuecomment-549225351