Message delimiting security issues

tis 2007-01-16 klockan 20:47 -0600 skrev William A. Rowe, Jr.:

> Security issues are caused by implementors.  Please reread the Watchfire
> report carefully to observe all the ways an implementor can do so.

The reports covers many possible permutations, but is not an
authoritative reference on what is or is not allowed by the specs. Some
of the constructs used is clearly invalid, most simply dubious
exploiting the fact that the specs is not clear.



Header names and implied LWS:
[I30] http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i30

Does the implied LWS rule apply to header names, even if it's not
allowed in MIME? Allowing LWS around the header name does not make
sense, but it is not explicitly forbidden.


I.e. is

Content-Length : 100

or if you like (equivalent)

Content-Length
 :100

valid HTTP headers, even if they are not valid MIME headers?



Double CR and end of headers:
[partly covered by I30]

Also is
<CR><CR><NL>

a blank header terminating the headers, or is it a invalid header line
consisting of a single <CR>?  Well, this one is clear (it's a <CR> line,
not blank), but unfortunately 19.3 encourages ignoring <CR> which easily
leads to implementations getting this wrong.



[no issue assigned]

And how SHOULD a recipient react if there is multiple Content-Length
headers?



These aspects is critical for defining the message delimiting within the
protocol, and still the specs is quite silent on the details which calls
for the kind of interoperability problems shown in the report.


Regards
Henrik