Subject: [quicwg/base-drafts] HTTP/3: behavior on unreasonable error cases (#4768)

From: Kazu Yamamoto <[email-masked]>
Date: Tue, 19 Jan 2021 16:38:46 -0800

It is clear that unknown error codes are treated as `H3_NO_ERROR` as written in Sec 8. But what about *known* stream errors in `CONNECTION_ERROR` or *known* connection errors in `RESET_STREAM`? For instance, what an endpoint should do in the case of `H3_CLOSED_CRITICAL_STREAM` in `RESET_STREAM`?

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 19 Jan 2021 16:51:13 -0800

(As an individual) This is a fair observation. But as noted on #4766, trying to enforce accurate usage of error codes is a rocky Road. 

A sensible approach is to hope that the error codes your peer receives might include a specific and accurate error code that can be used for offline debugging or analysis. 

In reality, implementations should be expect generic or inaccurate error codes to be generated by a peer. And it it is in their interests not to build too many runtime application behaviours on top of expectations that might not be met.

-- 
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/4768#issuecomment-763247742

---

From: Kazu Yamamoto <[email-masked]>
Date: Tue, 19 Jan 2021 17:16:30 -0800

Transport draft has this rule: "a generic error code (such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of specific error codes.". Could we use `H3_GENERAL_ERROR` for this purpose?

-- 
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/4768#issuecomment-763256787

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 19 Jan 2021 17:20:51 -0800

@kazu-yamamoto Yes, I think that is clarified in the definition of `H3_GENERIC_PROTOCOL_ERROR` (see [section 8.1](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-8.1)).

-- 
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/4768#issuecomment-763258317

---

From: Kazu Yamamoto <[email-masked]>
Date: Tue, 19 Jan 2021 22:15:56 -0800

@kazuho The definition of `H3_GENERIC_PROTOCOL_ERROR` is clear. But my point is that there is no rule to override any *received* HTTP/3 errors with `H3_GENERIC_PROTOCOL_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/4768#issuecomment-763364120

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 20 Jan 2021 03:50:39 -0800

I do not follow your argument about an endpoint rewriting the error code that it _receives_.

IIUC the text that you quoted in [your previous comment](https://github.com/quicwg/base-drafts/issues/4768#issuecomment-763256787) is about how a sender might choose an error code. I would also point out that, generally speaking, there is no reason to define how a receiver converts error codes internally. That is because it is something that does not need to be defined by an protocol specification.

-- 
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/4768#issuecomment-763551136

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Jan 2021 06:50:56 -0800

Agree with Kazuho that the instructions for error code usage are made from the error generator and sender, not the error receiver. 

-- 
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/4768#issuecomment-763664139

---

From: Kazu Yamamoto <[email-masked]>
Date: Wed, 20 Jan 2021 15:22:12 -0800

With the comments above, is the following interpretation correct?

- If `RESET_STREAM` is received and the error code is defined but not `H3_NO_ERROR`, the stream is reset.
- If `CONNECTION_CLOSE` is received, the connection is closed regardless of the error code.

-- 
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/4768#issuecomment-764019141

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Jan 2021 15:28:55 -0800

I think if you receive a RESET_STREAM then the stream is terminated regardless of the code that was provided. Specifically speaking, we require endpoints to handle unknown error codes - they can't do anything with them but they need to run the protocol machinery and NOT interpret the unknown code as an 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/4768#issuecomment-764022858

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jan 2021 15:31:06 -0800

Yes, RESET_STREAM ends the stream (in that direction), no matter the code.  Similarly, CONNECTION_CLOSE ends the connection, no matter the code.

The reason for the H3_NO_ERROR rule is that we don't want recipients doing something special in response to unknown codes.  They need to handle termination, but they can't do anything *else*.  Understanding the code might allow them to do other things, like retry requests or apply other rules, but that always needs to be discretionary.

-- 
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/4768#issuecomment-764024503

---

From: Kazu Yamamoto <[email-masked]>
Date: Wed, 20 Jan 2021 18:26:55 -0800

Thank you for your explanations. I would like to close this issue.

-- 
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/4768#issuecomment-764189536

---

From: Kazu Yamamoto <[email-masked]>
Date: Wed, 20 Jan 2021 18:26:56 -0800

Closed #4768.

-- 
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/4768#event-4231129904