Re: [quicwg/base-drafts] Separate HTTP/3 stream errors from connection errors. (#2911)

[Kazuho Oku <[e-mail]>]

@DaanDeMeyer 
> HTTP_NO_ERROR is only defined in the draft for usage in CONNECTION_CLOSE, I'm not sure when it would be used as a stream error (we have more specific error codes to indicate intent when closing a stream).

That's a good point. RFC 7540 uses NO_ERROR for instructing the client to stop sending the request when a response is provided early. In HTTP/3, we have created HTTP_EARLY_RESPONSE. But it might be a good idea to use HTTP_NO_ERROR in HTTP/3 too.

> HTTP_GENERAL_PROTOCOL_ERROR is only used as a stream error in the section discussing malformed requests/responses. I'd suggest using a more descriptive error for this case (HTTP_MALFORMED_MESSAGE for example) and treating HTTP_GENERAL_PROTOCOL_ERROR as solely a connection error.

HTTP_GENERAL_PROTOCOL_ERROR is a catch-all error code that can be for any reason. I'd prefer having that usable at stream-level too.

@LPardue 
> One of the thorny points to this discussion is that promotion of stream errors to connection errors is a feature of RFC 7540 Section 5.4.1

I'd prefer keeping the same design.

I think we need the freedom of promoting stream-level errors to connection errors. For example, when a server detects a suspicious activity by a client at a stream-level, it would make sense to close the connection.

-- 
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/issues/2911#issuecomment-513571273