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

Re: Message delimiting security issues

From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
Date: Wed, 17 Jan 2007 10:55:48 -0600
Message-ID: <45AE5514.7060304@rowe-clan.net>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Henrik Nordstrom <henrik@henriknordstrom.net>, Mark Nottingham <mnot@mnot.net>, Scott Lawrence <scott@skrb.org>, "Roy T.Fielding" <fielding@gbiv.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

Julian Reschke wrote:
> Travis Snoozy schrieb:
>> On Wed, Jan 17, 2007 at 11:47:33AM +0100, Henrik Nordstrom wrote:
>> <snip>
>>> 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.
>>
>> LWS is not allowed.
>>
>> <snip>
>>> Content-Length : 100
>>
>> BNF makes it clear.
>>
>> token          = 1*<any CHAR except CTLs or separators>
>> message-header = field-name ":" [ field-value ]
>> field-name     = token
>> separator      = [...] | SP | HT
>> ...
> 
> Are you aware of the "implied LWS" rule?
> (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1.p.11>).

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 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.

Bill
Received on Wednesday, 17 January 2007 16:56:28 GMT

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