Re: [quicwg/base-drafts] Replace HTTP_MALFORMED_FRAME error code (#2662)

[Kazuho Oku <[e-mail]>]

@LPardue 
>> I think my preference goes to merging INVALID_PRIORITY with FRAME_ERROR.
> 
> Thanks for the feedback. It's an easy change to make. I'll wait for some supporting or dissenting voices but otherwise will do this.

:+1:

>> Regarding rearranging the numbers, I wonder if it would be possible to split the error codes into two groups: connection-level error codes and stream-level ones. In contrary to HTTP/2, most of the HTTP/3 error code are either a connection-level error code or a stream-level error code, not both.
> 
> This resonates with my earlier analysis. Some of this was captured in #2816. But I think what you are suggesting is a slightly different thing. Can you explain what splitting might look like and how it would help? I think it gets complicated because 1) we may have a proxy that is trying to translate errors between H2 and H3. 2) stream errors can be upgraded to connection errors

IIUC, the following H3 error codes are used at both connection and stream level.

* HTTP_NO_ERROR
* HTTP_GENERAL_PROTOCOL_ERROR
* HTTP_INTERNAL_ERROR

The following codes are used only at connection level, though HTTP_EXCESSIVE_LOAD could be carried at stream level too.
* HTTP_STREAM_CREATION_ERROR
* HTTP_CLOSED_CRITICAL_STREAM
* HTTP_UNEXPECTED_FRAME
* HTTP_FRAME_ERROR
* HTTP_EXCESSIVE_LOAD
* HTTP_WRONG_STREAM
* HTTP_ID_ERROR
* HTTP_INVALID_PRIORITY
* HTTP_SETTINGS_ERROR
* HTTP_MISSING_SETTINGS

The following codes are stream-level errors. While they can be promoted to connection errors, doing so has a risk of resetting other requests inflight. Therefore I'd assume that they would generally be used only at stream-level.
* HTTP_REQUEST_REJECTED
* HTTP_REQUEST_CANCELLED
* HTTP_INCOMPLETE_REQUEST
* HTTP_EARLY_RESPONSE
* HTTP_CONNECT_ERROR
* HTTP_VERSION_FALLBACK

Therefore I thought that it might make sense to explain these three groups differently in the draft.

While I can see the desire to assign codepoints that overlap with HTTP/2, I am not sure if that's a good idea. Not only the error codes are different between H2 and H3, some H2 error codes map to QUIC transport-level errors. Considering the fact that there cannot be a one-to-one mapping, I'm afraid having overlap might backfire against us; it just creates an incentive to pass-through the error codes between different versions of the protocol.

-- 
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/2662#issuecomment-507529717