Subject: [quicwg/base-drafts] HTTP-31: Reserved Error codes (#4219)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 09:06:58 -0700

Section 6.2:

Recipients of unknown stream types MAY abort reading of the stream with an error code of H3_STREAM_CREATION_ERROR or a reserved error code (Section 8.1), but MUST NOT consider such streams to be a connection error of any kind.

So Section 8.1 does not explain what "reserved errror code" is. The only thing I found in that section is the formula for numbers that are equivalent to NO_ERROR which doesn't make sense to me in this context of clearly an error. Is there somewhere else that should be referenced or more explanation needed?

-- 
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/4219

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Oct 2020 11:58:57 -0700

Yes, this is referring to the set of error codes which are "reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR."  An unrecognized stream type could be a real extension which the recipient doesn't support, or might be a GREASE type.  Because of that, it seems appropriate to potentially use the GREASE error codes in response to such streams.

-- 
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/4219#issuecomment-709528753

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2020 00:59:22 -0700

Isn't it problematic for an HTTP/3 endpoint that receives a for it unknown stream type to abort it and respond H3_NO_ERROR. To me that looks potentially problematic as it might indicate something worked okay if that extension have the behavior of receiving a block of data and then close down the stream? Or should any of this extension anyway be negotiated using SETTINGS so this should never be an issue as the peer should know through that SETTINGS exchange what the peer is capable of? 

-- 
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/4219#issuecomment-709890894

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 16 Oct 2020 04:04:17 -0700

Since the unknown stream has to be ignored, I tend to think of the grease error codes as no-known-error.

As a general principle, endpoints shouldn't rely on error codes to determine too much. The error code sender is a liberty to be as specific or non-specific as it chooses.  

-- 
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/4219#issuecomment-709979244

---

From: Mike Bishop <[email-masked]>
Date: Fri, 16 Oct 2020 08:51:18 -0700

+1.  An extension that relied on knowing whether the receiver processed it needs to define a mechanism for the peer to acknowledge whatever state change is there.  We've taken a fairly steady stance that the application layer can't rely on transport acknowledgement as proof of application-layer processing.

-- 
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/4219#issuecomment-710128110

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Oct 2020 04:13:22 -0700

@gloinul do you still require changes after these explanations?

-- 
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/4219#issuecomment-712073904

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Oct 2020 23:46:04 -0700

No, I don't require changes. I still think there are a significant inconsistency to us "no-known-error" or as the actual code says "No Error" for something that is in fact a known error. Even if one select to be less specific there are other error codes that would be more correct. 

-- 
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/4219#issuecomment-712632045

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Oct 2020 05:20:41 -0700

Closed #4219.

-- 
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/4219#event-3898378101

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Oct 2020 05:20:41 -0700

OK, I am closing this now. If an editor feels like they want to address @gloinul's final comment above with an editorial PR, they can still do so.

-- 
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/4219#issuecomment-712809478