JSON numbers changed with leading zeros

I had this interesting case I was triaging last week where a consumer of our API was complaining that we were changing the value of numbers in request body when it had a leading zero. For example, instead of 052 becoming simply 52.0 it would transform to 42. Similarly 0100 would not output as a decimal of 100, it would become 64.

When a colleague of mine tested it he got the exact same results in our own carefully curated environments. So this was officially very strange!

I looked at this for a few days and just assumed that we were doing something incorrect with mapping of the types. However, Vignesh, made a discovery about the JSON number type that kind of took me by surprise. Leading zeros are not are not assumed to be numbers if it is not immediately followed by decimal point. Look at the following workflow used to determine if the input is a number type:

Here again the official spec reads as follows (emphasis mine):

2.4. Numbers

The representation of numbers is similar to that used in most programming languages. A number contains an integer component that
may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part.

Octal and hex forms are not allowed. Leading zeros are not allowed.
A fraction part is a decimal point followed by one or more digits.

An exponent part begins with the letter E in upper or lowercase, which may be followed by a plus or minus sign. The E and optional sign are followed by one or more digits...

So our inputs did not meet the definition of a number according to the JSON spec, which still leaves the question what is happening to our numbers with the leading zero? Well it appears that our particular JSON parser (from NewtonSoft) has been designed to read numbers in the octal format which goes above and beyond the JSON specification.

To quickly test this you can use any Octal to Decimal converter and see that our inputs of 052 and 0100 show up as the decimal equivalents of 42 and 64 respectively.

My thanks to Vignesh for the research here!