-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
