Subject: Re: [quicwg/base-drafts] Ambiguous wording about error codes in HTTP/3 (#3276)

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 04 Dec 2019 08:38:47 -0800

The paragraph in question (see [HTTP draft, section 8](https://tools.ietf.org/html/draft-ietf-quic-http-24#section-8)) talks about different things:

```
   Because new error codes can be defined without negotiation (see
   Section 9), receipt of an unknown error code or use of an error code
   in an unexpected context MUST NOT be treated as an error.  However,
   closing a stream can constitute an error regardless of the error code
   (see Section 4.1).
```

Let's break it up to make it easier to talk about:

1. Treating an unexpected error code as an error is not allowed, in particular:
a. Receiving unknown error is not an error in itself (a "further" error); and
b. Receiving an unexpected error code (known or unknown) is not an error.
1. A stream close may be an error independent of error code.

Item 1(a) follows from Section 9.  This does not need to be stated here.

Item 1(b) seems to suggest that error codes are not to be used to make decisions, for they could be anything, notwithstanding all the "MUST treat as error type" admonitions elsewhere in the code.  (This is what the text implies, which may not be what was intended.)

Item 2 says that some error occur due to changes in stream state and are not communicated via an error code from peer.

I would drop Items 1(a) and 1(b); Item 2 can be rephrased.

P.S. Given the loose treatment given to error codes by their recipient, it is logical to allow their sender to keep on treating specified errors as errors ("MUST treat as error..."), but allow setting the error codes to anything.  Stating that "MUST treat as error of type X and SHOULD set error code to X" sounds awkward; perhaps this guidance could be added to Section 8 as a new item.

-- 
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/3276#issuecomment-561727272

---

From: Mike Bishop <[email-masked]>
Date: Mon, 16 Dec 2019 08:01:13 -0800

1a/1b are two sides of the same coin.  Because error codes are extensible, a future document might define a new error code, or might prescribe the use of an existing error code in a new circumstance.  Therefore, the takeaway should be:

- An error code the recipient knows in an situation where they expect it has understood semantics that the recipient can act on.
- An unknown error code, or an error code in an unexpected situation, has semantics which the recipient does not understand and cannot act on.

The statement here is that the second case is not a violation of the protocol by the peer; you know the stream (or connection) is closing even if you don't understand why.  The admonition is to respond to the closure itself, not the unknown semantics of why it was closed.

While I agree that both versions of the second case follow from Section 9, I think it's useful to mention them in the context of error handling as well.  We've seen recently with HTTP/2 what happens when the possibility of extension values isn't mentioned/considered in the description of how the base-protocol pieces are to be handled.

-- 
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/3276#issuecomment-566123868