Re: Precision of numbers using JSON Header Field Values

--------
In message <20160716051253.GD21568@1wt.eu>, Willy Tarreau writes:

>I must say that right now I'm worried with the lack of distinction between
>an integer and a float. Some fields like a content-length or a byte-range
>definitely require a strict integer.

[1]

Well, that is true, but *in principle* there is nothing wrong with
transmitting it as "XXXXXX.000000" or even "1.2345e4", as long as
the receiver checks that the result is an integer.

And it's not like that is an issue JSON creates, we already perform
that very check today, but it is bundled up in a much stronger and
general check:  The field can only contain digits.

The trouble is the "we expect people to use generic JSON
parsers" assumption being tacitly made here.

Some fraction of generic JSON parsers store numbers as numbers in
their internal data structure[2].

If you use one of those, an hostile sender can force you to do
floating point math on any and all numeric fields.

We can of course write "If you use a generic JSON parser, make sure
it doesn't store numbers as numbers" but that makes the word "generic"
surplusage, doesn't it ?

We need to think about this problem at the meta level:

1) How are the content of these "structured headers" described in RFCs?

2) How does that description get turned into code which validates
   an input candidate ?

I belive answering that with "1: English Prose, 2: Programmers do
that" will cause far too much security vulnerabilities and interop
problems[3]

We _have_ to find a better answer than that.

Once we have I suspect the on-wire format will follow easily from that.

Poul-Henning

[1] Should array indices start at 0 or 1? My compromise of 0.5 was
    rejected without, I thought, proper consideration.
    	-- Stan Kelly-Bootle

[2] I-JSON imposes a 53 bit restiction on integers, to make it safe
    to store them in IEEE 754 binary64 floating point values.

[3] In exactly the same way "We'll just use JSON" has everywhere
    else.  I guess we'd "be following industry practice".

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Saturday, 16 July 2016 10:01:34 UTC