https://bz.apache.org/bugzilla/show_bug.cgi?id=66512
--- Comment #4 from Mark Thomas <ma...@apache.org> --- Thanks. It looks like a UTF-8 value is being put into an HTTP header. Prior to the refactoring of MessageBytes, that would have resulted in a corrupted header. Now it triggers an error to make the problem more obvious. That behavioural change was intentional. The reason you see the issue with AJP but not HTTP is that HTTP is coded more defensively. HTTP logs the problematic header with a warning and carries on. AJP fails the request. HTTP headers are expected to be US-ASCII. Non US-ASCII values should be encoded as per RFC 8187. To what extent that is an application responsibility vs a container responsibility is not made clear in the Servlet spec. I can look at making the AJP code more robust since it needs to be consistent with the HTTP code but that doesn't feel like a proper fix. It should also trigger quite a few warning messages in the logs which you would probably prefer not to see. Given that the application works either when the header is corrupted (using an old tomcat-util.jar) or when the header is missing (current HTTP code) that suggests whatever header is being set isn't necessary. Is not setting whatever header is causing the problem an option? (Assuming Tomcat is not setting it). -- 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
