Jens-G opened a new pull request, #3675:
URL: https://github.com/apache/thrift/pull/3675
Follow-up to the recent `TJSONProtocol` message-size changes.
`readJSONString()` and `readJSONNumericChars()` passed their running byte
count to
`checkReadBytesAvailable()`, which compares against the message size still
*remaining*
rather than the configured maximum. On a transport whose `read()` also draws
that budget
down, the same bytes are accounted for twice: once as they are consumed, and
once as the
running count.
`TZlibTransport::read()` does exactly that, so JSON over zlib rejects a
string once it
passes roughly half of whatever was left of the budget when the field
started -- and since
nothing resets the budget between fields, the threshold keeps shrinking as
the message goes
on. With a 1 KB maximum, a 768-byte string is cut off at 511 bytes.
This measures the running count against the configured maximum instead,
which is what the
Java, netstd, Delphi, Go and Python readers already do. Every transport that
checks the
budget without drawing it down -- socket, SSL, buffered, framed, memory,
HTTP -- behaves
exactly as before, because for those the remaining size never moves off the
maximum during
a read.
### Tests
- `JSONProtoTest.cpp` covers it transport-agnostically, with a stand-in that
draws the
budget down the way `TZlibTransport::read()` does (no zlib dependency, so
no conditional
build).
- `ZlibTest.cpp` covers the real composition.
Both new cases fail without the change and pass with it. `ZlibTest` (34
cases),
`JSONProtoTest` (17) and `UnitTests` (87) are green, built in `thrift:jammy`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
