https://bz.apache.org/bugzilla/show_bug.cgi?id=66196
Mark Thomas <ma...@apache.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW --- Comment #3 from Mark Thomas <ma...@apache.org> --- Generally, Tomcat doesn't validate response headers unless it needs to process them for some reason. Applications are expected to set valid data. This also gives applications the flexibility to bend (or even break) the HTTP specs which can sometimes be useful when dealing with clients that don't follow the specs. HTTP headers values are not restricted to US-ASCII. Many - including ETag - allow obs-text which is bytes in the range 0x80 to 0xFF. That said, RFC 9110 has a strong preference for US-ASCII. I suspect that requirement may get stronger over time. To add to the "fun" some cookies - despite RFC 6265 and the HTTP RFCs - have been observed to use UTF-8 values. And then there is RFC 8187 that I don't think I have ever seen in real world usage. So, in short, things are not at all clear cut. For HTTP/2, it will depend whether the implementation decides to use Huffman encoding or not. The specification doesn't define when to use Huffman and when not. You could argue that this imposes a requirement that the characters in header names and values must fall in the range 0x00 to 0xFF (other requirements limit this further). Which is stricter than HTTP/1.1. My thinking at this point was whether or not it was practical to add a similar limit to HTTP/1.1. Reviewing the code, I think it is. Only cookie headers are treated as UTF-8. All other headers are treated as ISO-8859-1. If you try passing in a String that uses characters above code point 255, they will get corrupted. On that basis, I think it is better to trigger an error early rather than passing corrupted data to the client. Triggering an error in the form of an exception problematic. Applications that appear to work at the moment would start failing once this change was applied. I think a reasonable compromise for HTTP/1.1 would be to log a warning (including the problematic String) and ignore the header. Thoughts? -- 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