- From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
- Date: Wed, 17 Jan 2007 10:55:48 -0600
- 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 UTC