Hi Mark, I confirm that all tests pass now! Thank you!
Martin On Wed, May 18, 2022 at 1:40 PM Mark Thomas <ma...@apache.org> wrote: > On 18/05/2022 10:25, Mark Thomas wrote: > > Hi all, > > > > So of the three issues Martin identified, I've fixed 1 & 3 which were > > the simple ones. > > > > For 1, the import handler needed updating to add the new classes added > > to java.lang in Java 19. > > > > For 3, the memory leak protection code that stops executor threads > > needed to be updated for some changes to Thread internals. > > > > The tricky one is 2. > > > > Prior to Java 19, the character -> byte encoders used an 8k buffer for > > character data. This aligned with Tomcat's internals. This meant that > > the new HEAD handling in the Servlet API had the same buffering > > behaviour as Tomact's internals so GET and HEAD behaved the same way. > > > > In Java 19, the character -> byte encoders start with a 512 byte buffer > > that may grow up to 8192 bytes. This means the buffering for HEAD > > handling is different to the buffering for GET handling which in turn > > means GET and HEAD see different headers (even accounting for allowed > > differences). > > > > The issue is when responses are committed (and headers are fixed). The > > HEAD tests examine the behaviour at the buffer boundaries including > > reset behaviour. GET and HEAD effectively having different buffer sizes > > triggers different behaviour for some of these resets which is why some > > fail. > > > > I'm currently thinking about ways to tackle this but I don't yet have a > > solution I'm completely happy with. Suggestions welcome. > > I found a solution. Since the issue was only with the legacy handling > mode for HEAD requests, adjusting the response buffer size to compensate > for the smaller char -> byte buffer addresses the issue. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
