Subject: Re: [quicwg/base-drafts] Some correctness issues in the HTTP/3 drafts are stream errors, not connection errors (#2511)

From: Daan De Meyer <[email-masked]>
Date: Wed, 24 Apr 2019 04:40:20 -0700

>From an implementation point of view, being able to classify an error as either a connection error or a stream error would simplify error reporting since we'd be able to classify an error as either a connection error or a stream error without having to include extra information with the error.

As an example, at the moment, when returning a `HTTP_MALFORMED_FRAME` error from a function, I have to include whether the `HTTP_MALFORMED_FRAME` is a stream error or a connection error since it can be both. If every error could be classified as either a connection error or a stream error, I wouldn't have to include this extra information since a `HTTP_MALFORMED_FRAME` error would always be a connection error.

-- 
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/2511#issuecomment-486187238

---

From: Mike Bishop <[email-masked]>
Date: Wed, 24 Apr 2019 10:45:25 -0700

@DaanDeMeyer, in keeping with HTTP/2, an endpoint can always decide to treat a stream error as a connection error.  However, you're correct that some (and after the associated PR, most) errors will always be connection errors, and your implementation could choose to always treat the others as stream errors.

Just make sure there's no issue if someone else decides to treat it as a connection error.

-- 
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/2511#issuecomment-486355940