https://bz.apache.org/bugzilla/show_bug.cgi?id=65802
--- Comment #6 from Nils R <renaud.n...@gmail.com> --- > If I'm reading this right, then returning a 400 response is entirely > inappropriate. Indeed, the HTTP 400 is returned when the client request is invalid. That's been the case for a long time for HTTP/1.1 requests, now it's true for HTTP/2.0 since 65785 which is another issue). > IMO throwing an exception would be the best behavior but if it's not > allowed/specified by the API itself or the javadoc, then I'm not sure how > much latitude we have for changing it. That's what I had in mind (throwing an exception), but of course, Tomcat has to be compliant with the Servlet spec. And I indeed, there is not much room left to throw an exception in the response flow. > I think the other one should be reverted since this is only a strict HTTP/1.1 > compatibility thing, since HTTP/2 is a binary protocol. Is there a really > real reason to limit it ? Other than spec lawyering of course. As I said before, the real reason to me are : - to behave the same between HTTP/1.1 and HTTP/2.0 (I checked the HTTP/3.0 draft, the same limitation is present) - there is already a validation of HTTP/2.0 header names : upper case characters are forbidden - to lower the risk of inconsistencies between different HTTP client/servers not behaving the same because this point of the RFC has been implemented in different ways by HTTP servers. (which may be considered as "spec lawyering" ^^') But one could argue it's an improvement not failing on illegal header names anymore, and not validating means spending less time processing the request. And I don't think there is any security holes because of this non-validation anyway. -- 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
