tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Http11NioProtocol error 505 (or 400)
Date Wed, 29 Dec 2010 02:53:03 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

On 12/28/2010 5:11 AM, André Warnier wrote:
> Business is slow these days, so let's muse a bit.

One of my favorite bands.

> There is no mention of a size limit for the headers part, nor any
> mention of any special ordering of the individual headers.

Yup.

> In other words, as far as the RFC is concerned, there could be a million
> header lines, and the "Host:" header could be the last one of them.
> (Except for a confusing example in section 5.1.2, but then, such things
> happen in RFCs).

Yup.

> In other words also, if Tomcat started to parse the request headers
> before it is sure to have all of them, it would have to store the
> results of such parsing in some temporary holding area, because at that
> point it may not have seen the "Host:" header yet, and thus not know
> which <Host> is supposed to handle this request (among other things).
> And this would offer a major opening for anyone wanting to mount a DOS
> attack : just send a few requests with very, very large header sections,
> to overwhelm this temporary holding area.

Agreed. The maxHttpHeaderSize setting is designed just for this
situation: Tomcat must buffer this information somehow, and the buffer
must be limited otherwise servers can be taken down.

This is a practical implementation detail that is not covered in the RFC
because it's just that: an implementation detail, which has no business
being in an RFC.

> I would thus imagine that the Tomcat developers in their wisdom seeked
> to prevent this

(NB for non-native English speakers: "seeked" is an incorrect past
imperfect conjugation of "seek". The proper past imperfect conjugation
is "sought". I know, right?)

> by implementing a limit to how large a HTTP headers
> section would be reasonably expected to be. And let's say that this is
> the maxHttpHeaderSize attribute, and that by default it is set to about
> 8KB.
> So the logic of reading the request reads it, up to either two
> consecutive CR/LF indicating the end of the headers, /or/ a limit of
> maxHttpHeaderSize bytes, and then declares that it has all the headers
> and attempts to parse them.

No, Tomcat should fail if the request line + headers (or maybe just the
headers after the request line?) exceed maxHttpHeaderSize. Otherwise, an
incomplete request might be processed incorrectly.

> That's the price to pay for avoiding the DOS attack.

Or even a resource exhaustion during normal operations.

> Now the optional /body/ of the request is something else, because by
> then Tomcat already knows which Host and which webapp should handle it,
> what format it is supposed to be in etc.., and can feed it to this
> webapp one chunk at a time, with or without blocking a Connector for the
> purpose.

Yup, and it's the webapp's responsibility to determine how to read the
request, buffer it, etc.: the container merely provides the API to read
the bytes.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0aoo8ACgkQ9CaO5/Lv0PAXbACfUZITh+Z+sfjXPCSSzlwyF97u
HTIAoJ3a7+ZVeCfncbKHOPtQ/XXenZ9E
=rpI5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message