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

Hi Mark,

2017-11-03 8:51 GMT+09:00 Mark Nottingham <mnot@mnot.net>:
> 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!

I agree that the chunk size problem is an interoperability issue, and
that it would be better to have a bar for the chunk sizes.

OTOH, to me it seems that the issue is rather exceptional. In chunked
encoding, transferring a 16GiB file as 16000 chunks (1MiB each) or as
2 chunks (8GiB each) are semantically equivalent. So we can avoid the
issue by capping the maximum permitted value.

Consider Content-Length or Content-Ranges. An endpoint needs to send
the value in some way. If we cap the maximum in Structured Headers,
then applications would be forced into finding their own way of
encoding (possibly by splitting a integer value to an array of
integers; e.g. upper 32-bits and lower 32-bits).

I would anticipate that the majority of our use-case is to send a
specific value (i.e. like Content-Length or Content-Ranges) rather
than chunked encoding. Hence arguing for not having an upper limit.

Having a guaranteed minimum (e.g., every implementation should at
least support NN bits) might not be a bad idea, but my stance is that
if we choose NN it should be no smaller than 64 since we might see
files that do not fit into 2^52 in next 20 years.

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

Yes. Under the assumption that other limits (e.g. header field length)
exceed the configured maximum.

It's just a different way of thinking.

IMO, things become complicated only when we consider that the numbers
are values that get converted to internal type (e.g. int64_t) by the
decoder of Structured Headers.

If we consider the decoder to only validate the type (i.e. check that
all the characters being used are digits) and return that to the
application as a string (which might get converted to intNN_t by an
application when it needs to use it), it becomes a non-issue.

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

I believe that it would be perfectly fine for a Web Application
Firewall to reject a HTTP message including some strange value. OTOH,
I do not see if a Firewall can determine if a value is suspiciously
large without knowning the meaning of the value. In other words, I
think that finding an unknown integer field of Structured Headers
would be no different to a Firewall to finding an unknown header
field. It does not impose any greater risk than observing an unknown
header field.

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



-- 
Kazuho Oku

Received on Friday, 3 November 2017 07:32:17 UTC