Jens-G opened a new pull request, #3518: URL: https://github.com/apache/thrift/pull/3518
## Summary - `HARD_MAX_FRAME_SIZE` (`0x3FFFFFFF`, ~1 GB) is a protocol-level structural constraint — the THeader frame length field is 30 bits wide. It is not a policy default. - All other Thrift bindings use `DEFAULT_MAX_FRAME_SIZE` (`16384000`, ~16 MB) as the default, matching the value in `TConfiguration` (C++, Java, Go, etc.). - Python's `THeaderTransport` and `TZlibTransport` were constructed with `HARD_MAX_FRAME_SIZE` as their default, leaving applications unprotected against oversized or malformed frames unless the caller explicitly called `set_max_frame_size()`. **Changes:** - Add `DEFAULT_MAX_FRAME_SIZE = 16384000` constant to `THeaderTransport.py` alongside `HARD_MAX_FRAME_SIZE` - Use `DEFAULT_MAX_FRAME_SIZE` as the constructor default for `_max_frame_size` and `_max_decompressed_size` in `THeaderTransport` - Use `DEFAULT_MAX_FRAME_SIZE` as the default for `max_decompressed_size` in `TZlibTransport` and `TZlibTransportFactory` - `HARD_MAX_FRAME_SIZE` is retained as the validation ceiling in `set_max_frame_size()` / `set_max_decompressed_size()` - Fix a pre-existing flake8 `E303` (too many blank lines) in `thrift_TZlibTransport.py` ## Test plan - [ ] Existing `THeaderTransport` and `TZlibTransport` tests pass - [ ] `flake8` clean on modified files - [ ] Verify default behaviour: a `THeaderTransport` constructed without arguments now rejects frames larger than 16384000 bytes without needing an explicit `set_max_frame_size()` call 🤖 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]
