W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 17 Nov 2016 09:01:35 +0100
To: Kazuho Oku <kazuhooku@gmail.com>, Willy Tarreau <w@1wt.eu>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <1775eacb-65e5-7339-0910-c2f1ca1fd457@gmx.de>
On 2016-11-17 08:17, Kazuho Oku wrote:
> Hi,
>
> 2016-11-17 14:53 GMT+09:00 Willy Tarreau <w@1wt.eu>:
>> Hi Kazuho,
>>
>> On Thu, Nov 17, 2016 at 10:06:04AM +0900, Kazuho Oku wrote:
>>> Hi,
>>>
>>> Thank you for writing the draft.
>>>
>>> Regarding the numbers, could we either exclude floating point from the
>>> specification or state that an integral number MUST be encoded without
>>> using a dot?
>>>
>>> The reason I ask is because it is hard to correctly implement a parser
>>> for floating point numbers, and a bug in the parser would likely lead
>>> to a vulnerability [1]. Note that in some (if not most) of the
>>> programming languages you would need to implement your own number
>>> parser to meet the needs. For example, you cannot use sscanf in C,
>>> because depending on the locale the function allows use of decimal
>>> points other than '.'.
>>>
>>> If we could exclude floating point numbers from the specification
>>> entirely or have a restriction something like above, parser
>>> implementors can refrain from implementing their own floating point
>>> number parsers until the specification in which they are interested in
>>> actually start using the notation.
>>>
>>> Non-integral numbers are rarely used in the HTTP headers. The only one
>>> I can recall is the q value of Accept-Encoding, but it is not a
>>> floating-point but actually a fixed-point number (of three decimals
>>> below the point), which could have been represented by using integral
>>> numbers between 0 to 1000.
>>>
>>>      weight = OWS ";" OWS "q=" qvalue
>>>      qvalue = ( "0" [ "." 0*3DIGIT ] )
>>>             / ( "1" [ "." 0*3("0") ] )
>>
>> I'd like to avoid FP as well. However it's important to note that fixed
>> point numbers is not exempt from similar issues due to the way they are
>> encoded, since everyone will store them in floats/doubles,
>
> Yes. Therefore, I believe that the we should discourage people from
> using fixed point numbers.
>
> For example, if we want to define a quality value like the one found
> in Accept-Encoding, we should not use three-digit fixed point numbers,
> but instead use an integral value between 0 to 1000.
>
> That way, we can totally avoid the issues introduced by a dot within a number.
> ...

+1 in general, but that approach wouldn't work well in cases where we 
want to allow different levels of precision (such as timestamps that 
optionally would allow fractions of seconds)

Best regards, Julian
Received on Thursday, 17 November 2016 08:02:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 November 2016 08:02:51 UTC