Enforcing RFC‑Strict Numeric Parsing in Production JSON Configurations

Recommended default: strict parsing in production

Set the production JSON parser to reject leading zeros unless you have confirmed that legacy configuration files cannot be rewritten and every downstream consumer tolerates non-canonical numbers. Strict parsing is the safer default because RFC 8259 permits only the literal 0 to begin with a zero; 01, 007, or 01.5 are invalid.

Criteria for choosing the default

• Source of truth. If your serialization pipeline generates the config, make it emit canonical numbers and enforce strict parsing everywhere.
• Downstream consumers. If other services or libraries parse the same file, strict parsing prevents silent divergence where one system reads 08 as eight and another rejects it.
• Migration cost. If production already ingests files with leading zeros, enable strict mode only after a one-time normalization pass, or you will cause ingestion failures.
• Parser version. Defaults differ by language and library version; do not assume the local parser's behavior matches production.

Confirmed behavior versus likely explanation

Item	Status	Detail
RFC 8259 numeric grammar	Confirmed	Leading zeros are prohibited except for the number 0.
Lenient local parse of 01	Likely	The local parser accepts the token and coerces it to 1; production rejects it.
Serialized leading zeros	Likely	Configuration serialization code is padding integers or emitting decimal strings with unnecessary zeros.

Steps for this case

1. Identify the production JSON library and version. The exact strict-mode flag depends on it.
2. Enable strict numeric parsing in the production config loader.
3. Replace any serialization that pads numbers with canonical numeric output.
4. Scan generated files programmatically for invalid numeric tokens instead of inspecting them by hand.
5. Add a parser-parity test so future changes cannot reintroduce mode divergence.

Verification without manual inspection

Use a script that walks the serialized text and flags numeric tokens matching a leading-zero pattern. Do not apply a global regex to the whole file, because timestamps, version strings, and quoted keys may contain zeros that are not JSON numbers.

# Illustrative Python; adapt to your language and JSON tokenizer.
import re

with open("config.json") as f:
    text = f.read()

# Flag unquoted numeric tokens that begin with an unnecessary zero.
for match in re.finditer(r"(?<=[:,\[\{]\s*)-?0[0-9]", text):
    print("Potential leading-zero number at", match.start())

A cleaner approach is to parse with the strict parser and compare its output against a round-trip serialization; any token the strict parser rejects is the violation.

Testing approach for identical outcomes

Load the same fixture file with two parser instances—one lenient, one strict—and assert that the resulting object graphs are equal. Then serialize the parsed object back to JSON and assert that no numeric token contains a leading zero. This catches cases where lenient mode silently accepts 01 while strict mode rejects it, and where serialization reintroduces padding.

Missing diagnostic detail: Which JSON library and version runs in production? That determines the exact strict-mode API or flag. Share it if you need the precise configuration line.