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

From: ianswett <[email-masked]>
Date: Sat, 09 Mar 2019 00:56:30 -0800

For consistency with PR #2508 and on-list discussion, there are multiple other places in the draft an error that indicates an incorrect implementation is treated as a stream error, not a connection error.

"Only servers can push; if a server receives a client-initiated push  stream, this MUST be treated as a stream error of type HTTP_WRONG_STREAM_DIRECTION."

"A PRIORITY frame received after other frames on a request stream MUST be treated as a stream error of type HTTP_UNEXPECTED_FRAME."

Unclear:
"A PRIORITY frame that references a non-existent Push ID, a Placeholder ID greater than the server's limit, or a Stream ID the client is not yet permitted to open MUST be treated as an HTTP_LIMIT_EXCEEDED error."

"A CANCEL_PUSH frame is sent on the control stream.  Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be treated as a stream error of type HTTP_WRONG_STREAM."

Possibly should be a connection error:
"A PRIORITY frame sent on a request stream with the Prioritized Element Type set to any value other than "11" or which expresses a dependency on a request with a greater Stream ID than the current stream MUST be treated as a stream error of type HTTP_MALFORMED_FRAME."

In the appendix:
"   SETTINGS_MAX_CONCURRENT_STREAMS:  QUIC controls the largest open
      Stream ID as part of its flow control logic.  Specifying
      SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error.

   SETTINGS_INITIAL_WINDOW_SIZE:  QUIC requires both stream and
      connection flow control window sizes to be specified in the
      initial transport handshake.  Specifying
      SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error.

   SETTINGS_MAX_FRAME_SIZE:  This setting has no equivalent in HTTP/3.
      Specifying it in the SETTINGS frame is 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/2511

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 09 Mar 2019 01:41:52 -0800

I'm ok with such changes but wonder if we should also add some further prose to the document that:

* highlights HTTP/3 difference to HTTP/2 i.e. "all errors are always connection errors"
* captures some of the guidance mentioned elsewhere like "identifying the stream on which a problem frame was delivered may be useful in error analysis, endpoints might want to include the stream ID in the reason phrase"

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

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 09 Mar 2019 01:55:07 -0800

@ianswett I'd forgotten about the settings appendix. This reads weird. Those settings are not formally defined in core HTTP/3 by name, so I wonder if the intention is that it is a "philosophical error". The code points are reserved, so we could suggest connection error on receipt. But we also have reserved grease code points that must be ignored.

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

---

From: ianswett <[email-masked]>
Date: Sat, 09 Mar 2019 05:51:24 -0800

I don't believe all errors are connection errors, even after Kazuho's PR, but I believe we could make that true with some changes.

For example, when too large a header is received, it's currently a stream error because it's not required you communicate your max header size, and if you don't, the peer can't expected to know the limit.

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

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 09 Mar 2019 06:11:22 -0800

The default value of SETTINGS_MAX_HEADER_LIST_SIZE is unlimited. Would you expect a peer to generate an excessive load error on a stream with the default?

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

---

From: ianswett <[email-masked]>
Date: Sat, 09 Mar 2019 06:17:58 -0800

The current text is:
"encountering a larger message header SHOULD be treated as a stream error of type "HTTP_EXCESSIVE_LOAD".  If an implementation wishes to advise its peer of this limit, it can be conveyed as a number of bytes in the "SETTINGS_MAX_HEADER_LIST_SIZE" parameter."

To me, the issue here is that a peer can have a limit, but is not required to advertise that limit.  If we required that if a peer has a limit, it must advertise it and enforce it, then closing the connection makes sense to me.

Given it's really easy to advertise it and it's within encryption, I don't see any reason not to make that change, but it's a slightly larger change than the other cases, where we're changing obviously avoidable errors to connection errors.

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

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 09 Mar 2019 06:34:32 -0800

Happy to spin off another issue.

> SETTINGS_MAX_HEADER_LIST_SIZE (0x6):  The default value is unlimited.
      See Section 5.1.1 for usage.

Is the intent here "unlimited, but not really and I may reject at any time without sharing my limit". How is a peer that broke the rule expected to recover from such 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/2511#issuecomment-471182925

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 09 Mar 2019 13:37:19 -0800

How about "an endpoint encountering a header list larger than the value advertised using SETTINGS_MAX_HEADER_LIST_SIZE parameter MUST close the connection with a connection error."

I do not think we should mandate the use of SETTINGS_MAX_HEADER_LIST_SIZE when imposing a limit on the header list size. This is because the maximum can be different between requests. For a proxy, the maximum size is actually unknown, because each origin would have different maximums.

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

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 09 Mar 2019 14:21:52 -0800

> PS. Though such a change would mandate the sender to respect SETTINGS_MAX_HEADER_LIST_SIZE (it's not required now).

Let me correct my self. This is wrong. By not forbidding responding with a connection error, we have been effectively mandating the sender to respect the settings parameter.

Therefore, I think we can clarify as an editorial change that a client MUST adhere the settings parameter, and then exceeding a limit becomes a protocol violation, which should be treated 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-471227594

---

From: ianswett <[email-masked]>
Date: Sat, 09 Mar 2019 15:31:09 -0800

Your text SGTM.  Since HTTP/3 is not yet at a 'higher bar', it doesn't matter too much as long as Mike agrees as well.

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