paulk-asert opened a new pull request, #2856: URL: https://github.com/apache/groovy/pull/2856
A digit run past the long range is converted with BigInteger, and one with a decimal point or exponent with BigDecimal. Both conversions are superlinear in the digit count and neither token was bounded anywhere in groovy-json, so a document of a few hundred KB cost seconds of CPU: a 400,000-digit number took about two seconds on every parser variant, and doubling the digits quadrupled the time. A number token longer than maxNumberLength is now rejected with a JsonException before the conversion that would pay for it. The default of 1000 characters matches Jackson's StreamReadConstraints, so JSON is bounded consistently with the Jackson-backed YAML/TOML/CSV slurpers, and follows the shape GROOVY-12064 established for nesting depth: a per instance setter on JsonSlurper and JsonSlurperClassic, the groovy.json.maxNumberLength system property to override globally, and a value of 0 or less to disable the check. Rejecting a 400,000-digit number now takes single-digit milliseconds instead of two seconds. All four JsonParserType variants and the classic parser funnel through their own conversion, so each enforces the bound where it reads the token. The INDEX_OVERLAY and LAX parsers defer conversion to first access, so they check while decoding rather than in NumberValue: a document over the limit is rejected by the parse that read it, not by a later read of the value. This tightens what the parsers accept. A number longer than 1000 characters that parsed before is now rejected by default; callers that legitimately carry such values can raise or disable the limit. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
