Re: Precision of numbers using JSON Header Field Values

[Kazuho Oku <[e-mail]>]

2016-07-15 13:13 GMT+09:00 Kazuho Oku <[e-mail]>:
> 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)

FYI the ruby's behavior has been fixed (see
https://github.com/ruby/ruby/commit/5292b2727a089821f2bf21dfcc8a7be899eb744c),
but anyways I agree with PHK and Julian that this illustrates the
danger of using a loose specification such as JSON.

> 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



-- 
Kazuho Oku