httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Korthof ...@organic.com>
Subject case insensitive, multi-line headers
Date Thu, 05 Feb 1998 01:20:59 GMT
I was looking for some unrelated information (safe characters w/ which to
identify the end of each header for internal communication between
different processes), and noticed a couple of things which seem incorrect
about how Apache handles headers for HTTP/1.1.

It looks as if we should be treating all header names in a case
insensitive manner.  It also looks like we're not dealing correctly with
headers which extend past a single line by placing a space or horizontal
tab at the begining of the second (or third, etc.) line.  If these aren't
correct in Apache currently, it's clearly not that big a deal (since it
works w/ all major clients) but if not, it'd be good to be HTTP/1.1
compliant.  Consider the following: 

-----
4.2 Message Headers

HTTP header fields, which include general-header (section 4.5), request-
header (section 5.3), response-header (section 6.2), and entity-header
(section 7.1) fields, follow the same generic format as that given in
Section 3.1 of RFC 822 [9]. Each header field consists of a name
followed by a colon (":") and the field value. Field names are case-
insensitive. The field value may be preceded by any amount of LWS,
though a single SP is preferred. Header fields can be extended over
multiple lines by preceding each extra line with at least one SP or HT.
Applications SHOULD follow "common form" when generating HTTP
constructs, since there might exist some implementations that fail to
accept anything beyond the common forms.
-----

(SP = space, HT = horizontal tab)

Am I missing something?  I haven't studied the document all that
carefully...  I was looking at

http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v11-spec-rev-01.txt

which is described as valid till May 21st of this year.


Btw -- I did do a patch to limit connections by IP; it is, as Dean noted,
rather ugly.  It's also an operation with linear running time, for all
that it's relatively fast (there's no way out of the O(n) running time
which I can see which isn't uglier and slower).  It does work on 1.2
servers (except Stronghold -- I'm sure I can fix that w/ a little work,
though), and I can probably adapt it for 1.3.  I'll see about putting it
in the patches directory of the Apache site...  it worked wonderfully for
us for preventing the kind of DoS attack described a bit earlier.  We
generally set the number of possible connections fairly high -- around 30
-- but that fixed it for us, since the DoS was coming from a broken piece
of software (shockwave on NT, for whatever reason).  Any limit can be
better than none.  It returns a 503 error, which makes it easy to track.

     -- Ed Korthof        |  Web Server Engineer --
     -- ed@organic.com    |  Organic Online, Inc --
     -- (415) 278-5676    |  Fax: (415) 284-6891 --



Mime
View raw message