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

From: HTTP issue updates <[email-masked]>
Date: Mon, 02 Apr 2018 06:41:07 +0000 (UTC)

Of course, if take that second approach, we'll be pretty much walking the same path as JSON numbers; good interop below the specified minimum, unknowable interop above it.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 02 Apr 2018 12:21:34 +0000 (UTC)

> but it wouldn't be required

I'm somewhat surprised that there's still that much optional behavior that in the long term can trip folks up.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 02 Apr 2018 23:32:45 +0000 (UTC)

@annevk you asked

> Or would implementations be allowed to have header-specific knowledge in the network stack and drop these headers on the floor there?

_allowed_ implies optionality. 

My assumption was that you were asking (for example) if a HTTP-aware middle box (let's say it's a WAF / "HTTP Firewall") could be made aware of what headers are structured (side channel, pre-configured, whatever), and decide to drop non-conforming messages as a result.

That's going to be the case -- if someone wants to do that, they're going to do it, and there's not much we can do about it. By the same token, we can't require everyone to deploy these things. So, it's optional.

We *can* require certain behaviours when software parses HTTP headers that refer to this specification, and that's what this issue is about. We can't require every piece of software in the path that sees the HTTP header to pay attention to this spec, however; some of them are going to just see it as a "dumb" string, i.e., a current HTTP/1.1 header.

A new version of HTTP might change that, if we can figure out how. But we're not doing that (yet).

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

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 10 Apr 2018 03:50:09 +0000 (UTC)

OK, my inclination is to take the second approach -- namely add some text that explains that what we specify are minimums, up to which interop is guaranteed, and beyond which is anybody's guess. 

That allows implementations to do fixed-size implementations if they want, and future serialisations to make assumptions about sizes as well, without requiring failure if a limit is hit. 

Does that make sense?

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

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 12 Apr 2018 02:08:26 +0000 (UTC)

See PR #578; comments / suggestions most welcome.

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