According to documentation maxSavePostSize=-1 means "disable limit". This was working fine in previous versions. With tomcat 10 this will trigger an exception when a ssl rehandshake is necessary: java.lang.IllegalArgumentException: capacity < 0: (-1 < 0) at java.base/java.nio.Buffer.createCapacityException(Buffer.java:279) at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:362) at org.apache.coyote.http11.filters.BufferedInputFilter.setLimit(BufferedInputFilter.java:69) at org.apache.coyote.http11.Http11Processor.sslReHandShake(Http11Processor.java:1285) Reason seems to be, that line 1285 of Http11Processor allocates a buffer with the size of maxSavePostSize without checking for the special meanings of 0 and -1.
A code inspection suggests that this hasn't been working in previous versions. While the special values of 0 and -1 work for FORM auth and HTTP upgrade, they do not work for TLS renegotiation. The different buffers in use (ByteBuffer for TLS, ByteChunk for FORM and upgrade) mean that implementing the special values for TLS without creating huge buffers for every connection will be non-trivial.
It looks like reverting to using ByteChunk to store the request body in BufferedInputFilter should fix this. Initial impressions are that this works but I want to run more tests before committing.
Fixed in: - 10.1.x for 10.1.0-M18 onwards - 10.0.x for 10.0.24 onwards - 9.0.x for 9.0.66 onwards - 8.5.x for 8.5.83 onwards