https://bz.apache.org/bugzilla/show_bug.cgi?id=62791
--- Comment #5 from Mark Thomas <ma...@apache.org> --- I agree the check is pointless for the reasons outlined in comment #3. Having looked at the openjdk source I think there is a lot of scope to clean this up. The TLS spec specifies a maximum of 2^14. Java defaults to this or, if jsse.SSLEngine.acceptLargeFragments is set, defaults to 2^15 to allow for non-compliant TLS stacks. After that any renegotiation of the app buffer size is only ever going to be downwards - not upwards - for any given session. The same goes for the packet buffer. I think we can remove the whole resize concept. We added it thinking the language in the Javadoc meant it could be resized upwards but my understanding of the code I have read is that it will only ever go downwards. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
