Re: New Version Notification for draft-nottingham-structured-headers-00.txt

On 2 Nov 2017, at 6:58 pm, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 
> To rephrase it my way, the question is if (and how) we can expect
> interoperability improvement by limiting the maximum of a integer
> value. Unless there is a reason, we should not have limits.
> 
> As you have stated, each endpoint will have their own limits, and they
> would not be able to handle values above that. So I basically agree
> with you that having a limit does not improve interoperability, while
> making things complicated.

I think I'm going to push back on that. 

Having a limit defined in structured headers means that a header defined using them is guaranteed that receiving implementations will be able to handle a known set of values. If the recipient doesn't, it isn't properly implementing structured headers, so the only thing it can do is ignore the header -- the correct behaviour for any header that isn't implemented.

We *could* specify a minimum bar (e.g., "all implementations must be able to handle integers at least as big as 2**32"), but then larger integers would work with some implementations, while not work with others -- which is an interoperability problem.

A header that might use those larger values would then need to specify how to handle that error. Since the whole point of structured headers is to take as much of that work off of the shoulders of header authors as possible, that doesn't seem good.

Likewise, if we don't specify any limit, we'll get into the situation Willy outlines -- developers will choose values that they think are reasonable, until they get bug reports. Those bug reports *are* interoperability problems!

Again, I'll assert that not every numeric value that could possibly be transferred in HTTP needs to fit into structured headers; new headers don't have to use them, and we can add more structures later on if necessary. 


> The only case I could expect an improvement by having a hard limit is
> when an intermediary is involved.
> 
> Consider the case in which we have a proxy that can only handle
> integer values under 2^32. The proxy rejects forwarding messages with
> a greater integer value included at any place within the message,
> regardless of if it is actually using the value.
> 
> If we had limited the maximum to 2^32-1, the client and the server
> trying to communicate a value greater than 2^32-1 will be forced to
> use something other than an integer type. At the cost of complexity,
> the two would be possible to communicate with each other through the
> proxy.
> 
> But if we have no limits, the two will encode values greater than
> 2^32-1 as integers, and the proxy will refuse to forward the message.
> 
> Fortunately, I think that the problem can be made a non-issue by
> clarifying that intermediaries must not refuse to forward messages
> when it finds an integer value greater than it can parse in a header
> field attribute that it does not use.
> 
> What do you think about adding such a requirement?

If an intermediary finds an integer greater than 2**64 in a value, you're saying that it is required to forward it? What if it's e.g., 2**2048? 2**16384?

Intermediaries inspect header values all the time, and they need to be able to refuse to forward a message for any reason. E.g., Web Application Firewalls.


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 2 November 2017 23:51:33 UTC