Hash: SHA256


On 3/23/20 09:01, Mark Thomas wrote:
> Hi,
> I am currently looking at the request line parsing. I'll try and
> set out each issue in turn.
> End of line parsing ===================
> Prior to the recent changes, Tomcat allowed CRLF or LF to mark the
> end of a line. The unwanted side effect was that CR could appear in
> the header value. This caused problems and was tightened up to only
> allow CRLF as a line terminator.
> Currently Tomcat requires CRLF everywhere apart from the end of
> the request line for a HTTP 0.9 request where it also allows LF.
> This requirement to accept just LF as a line terminator first
> emerged in the W3C spec [1]. RFC 1945 [2] and RFC 2616 [3] retained
> this as a recommendation for all line terminators, RFC 7230 [4] no
> longer includes this recommendation.
> RFC 7230 also removes the expectation that a server that supports
> HTTP/1.1 will support HTTP 0.9.
> Arguably the current spec for HTTP/0.9 is [3].
> The Servlet spec references RFC 7230 and RFC 1945 so arguably
> HTTP/0.9 support is expected.
> SP vs whitespace ================
> Tomcat currently accepts any combination of SP and HTAB where RFC
> 7230 calls for a single SP. This stems from a recommendation in RFC
> 2616 which is no longer present in RFC 7230.
> I think we have three options.
> 1. No changes. CRLF is required everywhere apart from HTTP/0.9
> where LF is also accepted. Any combination of SP/HTAB is accepted
> where SP is required.
> 2. Tighten up as per RFC 7230 a) Require CRLF for all line endings
> b) Require SP where specified c) Drop HTTP/0.9 support
> 3. Relax the recent changes to allow CRLF or LF as a line
> terminator everywhere without allowing CR to appear in a request
> header.
> I think we should follow 1) for Tomcat 7, 8 & 9.


> I'm leaning towards 1 for 10.0.x as well with a view to discussing
> 2 in the Servlet project. i.e. explicitly dropping HTTP 0.9 support
> and the "Tolerant applications" requirements of RFC 1945 for
> Jakarta EE 10 (Tomcat 10.1.x).
> In short this means largely do nothing apart from may be adding a
> few more tests to explicitly check behaviour for various edge
> cases.
> I'll note that the regressions reported with the recent change to
> requiring CRLF as a line terminator caused issues with valid
> HTTP/0.9 requests but that this should now be resolved.
> We have had one user issue reported where a custom client was using
> LFLF as a line terminator and requests are now being rejected.
> Given that was never valid, I'm OK with that.


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.

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.

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.

- -chris
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


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

Reply via email to