W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: Message delimiting security issues

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 17 Jan 2007 20:45:58 +0100
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <1169063158.12807.131.camel@henriknordstrom.net>
ons 2007-01-17 klockan 10:55 -0600 skrev William A. Rowe, Jr.:

> Precisely.  It must be accepted, because spaces are allowed between words
> and between word delimiters.  But it must not be transmitted because the
> spec is quite clear in it's construction.  The reporter of issue 30 seems
> to think it's ambiguous, it's not.  Unless EXPLICITLY prohibited LWS is
> accepted.

In this specific case I am leaning more towards that there was an
oversight in the wording of 4.2, forgetting to mention that LWS is not
allowed between the header name and the delimiter. The reasoning being

a) It's not allowed by MIME, which the HTTP header syntax is supposed to
build upon.

b) Clearly not expected to most readers.

c) And nearly all implementations gets this wrong one way or another.


As it's very doubtful there is any implementations relying on this being
allowed today, and the security implications of implementations not
properly ignoring the LWS the question is if 4.2 should be strengthened
disallowing LWS between the header name and the separator (also in line
with MIME header syntax), or if the current messy situation should be
kept relying on each implementer to figure out the implications of
implied *LWS..

> In the case of LWS before a header argument, that's absolutely not valid
> data.  Again, the reporter of issue 30 seems to be confused about the
> distinction between an implementation and a spec.

You mean LWS before a header name? No one has ever claimed that to be
valid, not even the reporter of I30. There is just an observation that
many implementations gets it wrong.

Regards
Henrik



Received on Wednesday, 17 January 2007 19:46:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:00 GMT