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

[Daan De Meyer <[e-mail]>]

> 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.

PROTOCOL_ERROR sounds to me like something that mandates closing the connection. I do agree with having a catch-all error code for streams as well but I'd just add HTTP_GENERAL_STREAM_ERROR instead of reusing HTTP_GENERAL_PROTOCOl_ERROR. It avoids confusion of whether PROTOCOL_ERROR closed a single stream or the entire connection. 

> 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.

Why do we need promotion for this? Closing the connection because of suspicious activity at the stream level sounds like a clear use-case for a connection level error such as HTTP_SUSPICIOUS_ACTIVITY (I don't think we should actually add this).

More generically, if an error at the stream level (clearly intended not to close the entire connection since its a stream level error) causes the entire connection to be closed, that should be communicated with a connection level error instead of a stream level error. Many of the current stream level errors don't make any sense at all when used in the context of a connection level error. Instead, if a stream error could possibly mandate closing the entire connection, it should have a corresponding connection level error that more clearly indicates why a stream level error caused the the entire connection to be closed.


-- 
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-513576440