Precision of numbers using JSON Header Field Values

Hello,

I have a question about how numbers are going to be handled using JSON
Header Field Values.

In section 6.1, the draft uses Content-Length header as an example,
and states that in case the header is to be represented using JSON,
the definition should "restrict all numbers to be non-negative
integers without fractions."

Does this mean that numbers should not be expressed using the
exponential notation (which would mean that we would be adding a
restriction to JSON encoder / parser), or does it mean that we should
validate the number _after_ parsing it using method defined in RFC
7159?

The reason I ask is because RFC 7159 does not define the precision of
numbers, and in some cases existing JSON decoders disagree in how the
number expressions are parsed.

For example, using node.js v.6.2.1,
0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100e400
is evaluated as 100. OTOH, using ruby 2.0.0, the same expression is
interpreted as zero.
(please refer to
https://gist.github.com/kazuho/7e72372111fa0655692d9e44be70c7ea for
the full output)

IMO such disagreement is a mine of vulnerabilities.  For example in
case of HTTP/1.1, it could lead to HTTP response splitting.

So personally, I think we should forbid the use of exponential
notation at least in some cases, but I wonder if adding such
restriction is intended or aligns with the motive to use an existing
notation for HTTP headers.

-- 
Kazuho Oku

Received on Friday, 15 July 2016 04:13:59 UTC