On 23/03/2020 14:59, Christopher Schultz wrote:


> 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

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.


To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to