W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Implied LWS questions

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 06 Jun 2008 17:46:28 +0200
Message-ID: <48495BD4.2050001@gmx.de>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
CC: ietf-http-wg@w3.org

Frank Ellermann wrote:
> Julian Reschke wrote:
>>    HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT"
>> So, do "HTTP" and "/" qualify as instances of quoted-string?
>> What about 1*DIGIT? That's definitively not a quoted string,
>> but it could be parsed as token.
> An 822-parser would "see" any <specials> including ".", but 
> not "/".  Based on that the old syntax could be misleading,
> how about this:
> | HTTP-Version   = ( "HTTP/" 1*DIGIT "." 1*DIGIT" ) / obs-version
> |
> | obs-version    = "HTTP/" 1*DIGIT *WSP "." *WSP 1*DIGIT

Well, for now I'm not trying to change anything, just to come to a 
common understanding about what RFC2616 *really* says.

> No *WSP before or after the slash.  IIRC we already agreed
> that there can't be any folding, otherwise LWS would result
> in [FWS] instead of *WSP.

Again, see above.

> Please don't say *LWS, more than one adjacent LWS makes no
> sense.  A single LWS already allows multiple line foldings,
> a *LWS buys you nothing apart from confusing readers... :-)

The rule is called "implied *LWS", but then it doesn't state whether 
it's really "*LWS" or "[ LWS ]".

And yes, *LWS and [ LWS ] are different; the latter only allows one CRLF.

>> the specification imports BNF rules from RFC2396:
> RFC 3986 has an appendix with translations of old constructs. 

>> does http-URL allow *LWS anywhere?
> No, RFC 2396 has no #-LWS horrors, and STD 66 is anyway clean.
> RFC 2616 didn't introduce LWS in RFC 2396 http URIs <shudder />

I do agree that it would be non-sense to introduce it; right now I'm 
just trying to understand whether there *is* a mechanical way to 
transform the RFC2616 ABNF so that the implied LWS rule can go.

BR, Julian
Received on Friday, 6 June 2008 15:47:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:46 UTC