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

Hi Willy,

2017-11-02 14:54 GMT+09:00 Willy Tarreau <w@1wt.eu>:
> Hi Kazuho,
>
> On Thu, Nov 02, 2017 at 02:18:23PM +0900, Kazuho Oku wrote:
>>>> IMO, we need to at least have a representation that can carry the size
>>>> of the file, which cannot always be represented as a i32 value. So the
>>>> introduction of a sized type (i.e. i32, i64) means that we would need
>>>> to have _two_ decoders for numbers, instead of one.
>>>>
>>>> My question here is what the merit of having two decoders is.
>>>
>>> If you need to support integers of such large size, I think we're already talking about two decoders, because we need to support floats too.
>>
>> I can understand your point that we would be having at least two
>> parsers, one for integers and one for floats (or three, if we consider
>> positive and negative integers as different types). But still, I am
>> not sure if the fact justifies having multiple parsers for different
>> sizes of integer types, since, as I stated, I do not see if there
>> would be any practical merit (e.g., interoperability improvement).
>
> In fact I think the root cause of the problem is that we must consider
> the failure to parse as something normal, and not something which never
> happens. Ie: a 32-bit content-length can be perfectly fine for many use
> cases (probably 99.99%), but what is not acceptable is that the parser
> silently fails to parse larger values and wraps or returns -1 or such a
> thing.
>
> Thus I'd rather suggest that number parsers MUST be able to correctly
> parse all sizes supported by the implementation AND detect their own
> failures to do so.

I think that this is a powerful argument.

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.

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?

> Personally I don't care if "q=0.33333" is rounded down to "q=0.25" or up
> to "q=0.5" by an implementation which uses fixed floats with only 1 or 2
> decimal bits, if that suits their needs. But integers must always be exact.
>
> That's why I think that variable-length encoding can help (in fact ASCII
> encoding actually *is* variable length encoding, just a very inefficient
> format). All implementations can be compatible with their target use cases
> without having to deal with difficult types.
>
> (...)
>> For floats, first let me state that I do not know if we even need to
>> support it. To me it seems worth considering to drop it, as PHK
>> suggested.
>
> +1. We can define that "q=" is specified in thousands for example and
> that only 3 decimals have to be parsed there.
>
> Willy



-- 
Kazuho Oku

Received on Thursday, 2 November 2017 07:59:21 UTC