Summary: | java.lang.ArrayIndexOutOfBoundsException when a servlet writes more than the output buffer max length on a connection to be upgraded to HTTP/2 | ||
---|---|---|---|
Product: | Tomcat 8 | Reporter: | Ludovic Pénet <l.penet> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | regression | ||
Priority: | P2 | ||
Version: | 8.5.8 | ||
Target Milestone: | ---- | ||
Hardware: | PC | ||
OS: | Linux |
Description
Ludovic Pénet
2016-12-07 16:05:04 UTC
Well, my first analysis of this problem was wrong. After further debugging, it appears that the problem is rather in the "Content-Disposition" header value. As we are in France, it sometimes contains non ascii chars. In this case, char é caused the exception in HPackHuffman.encode. So, I changed the way I set the header from : resp.setHeader("Content-Disposition", "attachment;filename=\"" + filename + "\""); to : URLEncoder enc = new URLEncoder(); resp.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + enc.encode(filename, "UTF-8")); and it works. This one is worth reading: http://stackoverflow.com/a/30446122/696632 Agreed. I left the bug opened because the exception raised was quite unclear to me and having another error trace would be great. Neither the HTTP/2 spec nor the HPACK spec define the encoding to be used to convert characters to bytes for header values once you step outside of ASCII so to some extent this is going to be a lottery. Tomcat's implementation was meant to use the unicode code point but failed to take account of the fact the byte is signed in Java. I've fixed this and improved the error message if you try to send a header containing a character with a code point above 255. I also added some test cases. As an aside, your original example should now work. Fixed in: - trunk for 9.0.0.M15 onwards - 8.5.x for 8.5.10 onwards |