Subject: Re: [httpwg/http-extensions] Length limits on types (#433)

From: HTTP issue updates <[email-masked]>
Date: Tue, 27 Mar 2018 23:20:26 -0700

Discussed in London; see:
  https://github.com/httpwg/wg-materials/blob/gh-pages/ietf101/minutes.md#header-common-structure---mark-nottingham

I think the most relevant question is whether we want to limit individual structures (beyond numbers, which are a special case; e.g., string length, number of items in a list, etc.), or whether we just want to limit header size. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/433#issuecomment-376774868

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 28 Mar 2018 07:15:43 +0000 (UTC)

My main worry here is where this limit is allowed to be imposed. If someone goes beyond this limit, is there still a guarantee that the header can be obtained through a non-structured API? Or would implementations be allowed to have header-specific knowledge in the network stack and drop these headers on the floor there?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/433#issuecomment-376786033

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 28 Mar 2018 01:25:59 -0700

Leave that up to the individual header definitions? An implementation that knows whether a header is structured or not can know more specific semantics for that header.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/433#issuecomment-376803859

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 29 Mar 2018 17:46:10 -0700

Stepping back - to me, a large part of the motivation for including limits IMO is two things:

1. To assure that there aren't arbitrary differences between the capabilities / built-in limits of implementations (thereby causing interop or even security issues).
2. To provide fallback limits for authors who forget to specify them.

I'd also observe that overall header length limits are imposed by HTTP implementations themselves, which is often going to be separate from structured header implementations.

I think this convinces me that we should keep the limits in their current form, and that they should probably be made pretty big (esp. strings) so that they are hit less often.

Current limits / what I propose:

* Dictionary - 1024 members / 4096 members
* List - 1024 members / 4096 members
* Parameterised Lists (items) - 256 items / 1024 items
* Parameterised Lists (parameters per item) - 256 parameters / 256 parameters
* Strings - 1024 characters / 8192 characters
* Identifiers - 256 characters / 256 characters
* Binary Content -  16384 bytes / 16384 bytes

Thoughts?

Another approach would be to require parsers to support at least so many characters / items / etc., rather than fixing maximums. That would address (1) above but not (2). That might be OK, since overall header length will probably kick in as an abuse control before many of these.

@annevk - I think an implementation (whether server or client) *could* drop what it knows to be a structured header onto the floor if it violated the limits, but it wouldn't be required; the only requirement is on someone actually running as a parser.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/433#issuecomment-377414059