On 23/03/2020 14:59, Christopher Schultz wrote: <snip/>
> My only concern here is that request line + header-processing really > has to match whatever reverse proxy servers are doing as well, and > that's really not something we can know for sure. I don't think there > is a single safe implementation that will make everyone happy. I think everything is, slowly, getting stricter. Generally as a result of request smuggling vulnerabilities and the like. > Is there a way to make this kind of thing pluggable with a few obvious > implementations so that users can select which one makes the most > sense for their environment? Similar to cookie-proessing, we could > have a super-spec-compliant one which always requires CRLF line > endings (which I guess means dropping support for HTTP 0.9), and is > super strict about everything else. Yes, it is possible. I'm not sure if truly pluggable or configurable makes the most sense. I haven't looked at it too closely. > Another implementation could work the way Tomcat currently behaves, > being mostly spec-compliant and a little tolerant of some sloppiness. > > This will allow an environment where e.g. httpd is in use to use one > implementation while Squid, IIS, nginx, etc. can make different > choices depending upon how the proxy will interpret things. > > I realize that means more code. :( But if the proxy and origin server > disagree about how to interpret things, Bad Things can happen. If we > take a very strict interpretation of everything, I think we can > actually make the origin server safe, but we may break environments > which are relying on non-strict behavior. So far, the biggest breakage was caused by a regression in Tomcat's parsing of valid HTTP/0.9 requests. The approach you describe wouldn't address that sort of issue. We have had one additional report of new breakage with a client that uses LFLF as the line terminator but has never been valid and it was pure luck that Tomcat used to allow it - it was never intended to be allowed. My preference at this point is to concentrate on improving the unit tests to reduce the chances of regressions as and when we do make changes to the parsing code. I'm not completely against making request line (and header) parsing pluggable / configurable but relaxing parsing goes against the current direction we have been heading in and I'd need a lot of convincing to support such an approach. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
