Subject: Re: [quicwg/base-drafts] Robert Wilton's QPACK Comment 3 (#4802)

From: Lars Eggert <[email-masked]>
Date: Mon, 01 Feb 2021 05:06:52 -0800

So, do we have a proposal on this one?

-- 
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/4802#issuecomment-770843294

---

From: Mike Bishop <[email-masked]>
Date: Mon, 01 Feb 2021 06:22:43 -0800

> @afrind, remember that MAX_FIELD_SECTION_SIZE is advisory, so I wouldn't go so far as to say "practical".

Every (sane) implementation _has_ a limit; what's advisory is informing your peer about your limit before they hit it, or enforcing downstream limits to short-circuit errors.  Any implementation could absolutely tell the decoder not to bother decoding anything larger than what they will process and just return 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/4802#issuecomment-770892604

---

From: afrind <[email-masked]>
Date: Mon, 01 Feb 2021 11:29:26 -0800

I'm trying to address Robert's second point:

> (2) Senders probably won't really know that the reason the stream has failed is because they are hitting some arbitrary limit in the receiver, and even if they did then I'm not sure there is anything that they can do about it.

The mechanism to address that in HTTP/3 is with the advisory setting, though it's slightly different in that the setting applies to the entire field section, and it's conceivable an implementation could have another, smaller limit for any individual field name or value.  It's easier to pretend that isn't the case.

For these reasons, I stumbled a bit on the exact wording of the text last week and ran out of time because of other commitments.

I'm thinking something along the lines of

 "an implementation really ought to be able to decode a string as long as their advisory setting"   

and/or

 "if an implementation has a limit on the maximum size of string it can decode, it would be really nice to inform the peer about it with the advisory setting".
 
Is that reasonable?  Or am I barking up the completely wrong tree?

-- 
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/4802#issuecomment-771100337

---

From: Robert Wilton <[email-masked]>
Date: Tue, 02 Feb 2021 01:09:26 -0800

If HTTP/3 already sets practical limits on what the QPACK needs to accept then it is fine to say that.

Or to put this another way, the HTTP/3 implementations presumably are setting limits (or perhaps they are just relying on language/decoder limits).  How are they deciding what those limits should be?  How can they be sure that they will interoperate with all senders?

I'm not an HTTP expert, so perhaps I'm missing something obvious here.

-- 
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/4802#issuecomment-771484898

---

From: Mike Bishop <[email-masked]>
Date: Tue, 02 Feb 2021 07:13:03 -0800

HTTP (not HTTP/3) has historically not communicated those limits, which are implementation-dependent.  You just find out if you hit them -- status codes 413 (Content Too Large) and 414 (URI Too Long) cover these, but some implementations will also send a 400 out of discretion.

HTTP/2 introduced a mechanism to inform the peer what your limit is (SETTINGS_MAX_HEADER_LIST_SIZE), which lets the failure occur further downstream and saves everyone effort -- a client or downstream proxy can fail a too-large request on behalf of the server before actually transferring it, rather than discovering the limit only after the server rejects it.  It's optional, though; some endpoints prefer not to disclose their limits to avoid giving information to attackers, and some endpoints don't know how big the message is going to be when it starts processing it.  HTTP/3 maintains parity with that (SETTINGS_MAX_FIELD_SECTION_SIZE) and the feature is similarly optional.

Regardless of whether they're communicated, though, sane implementations *have* a limit.  In at least some implementations, this limit is configurable, so it can be increased in situations where you have mostly-trusted clients and a known usecase for very large headers or URIs.  That's not a protocol element; I don't think we can reasonably say much more than that the QPACK library SHOULD/MUST be able to process the largest individual header or header section that its HTTP implementation can be configured to accept.

-- 
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/4802#issuecomment-771704210

---

From: Robert Wilton <[email-masked]>
Date: Tue, 02 Feb 2021 07:24:28 -0800

Mike, thanks for the additional context.

Stating something along the lines of the following would be fine with me:
 - sane implementations have a limit (and what they do if that limit is reached), and
 - the QPACK library SHOULD/MUST be able to process the largest individual header or header section that its HTTP implementation can be configured to accept.

-- 
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/4802#issuecomment-771712271

---

From: afrind <[email-masked]>
Date: Tue, 02 Feb 2021 15:06:13 -0800

Closed #4802 via #4823.

-- 
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/4802#event-4282222439

---

From: afrind <[email-masked]>
Date: Tue, 02 Feb 2021 15:06:28 -0800

Reopened #4802.

-- 
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/4802#event-4282223244

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 21 Feb 2021 15:07:54 -0800

Closing this now that the IESG have approved the document and it's with the RFC editor.

-- 
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/4802#issuecomment-782945520

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 21 Feb 2021 15:07:56 -0800

Closed #4802.

-- 
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/4802#event-4356904526