liotur opened a new pull request, #1092: URL: https://github.com/apache/tomcat/pull/1092
https://bz.apache.org/bugzilla/show_bug.cgi?id=69617 The `maxHttpRequestHeaderSize` documentation already warns that the full amount is allocated for every request, but not that the allocation outlives the requests that caused it. `Http11InputBuffer.recycle()` leaves the `ByteBuffer` in place and only resets its position and limit, so it survives `Http11Processor.recycle()` and stays reachable for as long as the processor sits in the connection handler's recycled processor stack, which is bounded by `processorCache` (200 by default). On a keep-alive connection the processor goes back to that stack between requests as well. `Http11OutputBuffer` allocates `maxHttpResponseHeaderSize` in its constructor and retains it the same way, and `maxHttpHeaderSize` provides the default for both. I kept this change to the attribute the bug is about; happy to add a matching note under `maxHttpResponseHeaderSize` if you prefer. --- (Saved to /Users/armanp/workspace/github-contributing/PR-tomcat-69617.md and .title. Not posted anywhere. Every sentence is verifiable from the clone: Http11InputBuffer.java:78 and :245, Http11Processor.java:174 and :1436, Http11OutputBuffer.java:115, AbstractProtocol.java:1168/:1386-1392/:1541/:1669, webapps/docs/config/http.xml:610 and :716.) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
