-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 3/23/20 11:35, Mark Thomas wrote: > 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. Sounds good. I entirely missed your actual proposal, which was below your signature and after your references: On 3/23/20 09:01, Mark Thomas wrote: > With all of the above in mind I propose: > > - Doing nothing! I think Tomcat is striking the right balance > here. > > This means: GET /CRLF -> processed as HTTP/0.9 GET /LF -> > processed as HTTP/0.9 GET / CRLF -> processed as HTTP/1.1 and > rejected as invalid GET / LF -> processed as HTTP/1.1 and > rejected as invalid > > I want to write some tests to check this is behaving as expected > but I'm not expecting any changes to the parsing at this point. I think I like the above very much. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl548uMACgkQHPApP6U8 pFgZRQ/+KCX+EgM6+5FLDacDw2dy0mFSdCkjnWKcq2WbgwZe6GbNeGra0Egme9GF CsJmVwrHnv34y+VKuvugoKVxDMyvsrkIrLyYPyW+VJg+iualK74BEI/28lvMGt2M 4RuPofhNQNmNxbWP1cvcWGb1CEinVo97AU3lHjRHRCtWWL5jQhiO9te9GWk2Q9z9 EmLJZo/tS+PSYLx73ewFEN0BxH7exQAu3MsYNxtq/be7pEDj4kJF5tXY6vnSXbmX upZ14tBpw/loy6aC/Ay56Nx76q/t0+J4ZNsYgsNf3OeowCYnWFw8orbM5rCVFuY2 CshC40F+rhc1IZfcVd4F34SqRGs3W47eA4/CHnKBHBMA8R6Oj76gJkJvn3izRLYH y5L8kHc3umXXDYQkDYgytGzGDaaXx0+OKaZHLywV6rXw30DvANh6xhsW+7GKqqI6 8FckjrQeCrBzBg+tSz+ObeHJxZvhpD5CYg5vjH8YxXKL6hi65k+IaaOgydmjq2SQ lnoMIfdmydxRYnmhmzfCcJdgxkctvg3AGyidG2zEWE8EYbAfzixb9PVDZEhb4lMk wBE5wj2IUmgsmFV/MdUfQjZNFn8dEoZbjebrrIyUlsLJng7AIObXss3myp6DZJXt OWSjnMGVcsvXzbpfs/nw9kFnkdEMFbzDnVVGBDf93KygLQqEgCM= =zQMS -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
