Re: implied LWS scope

Alex Rousskov wrote:
> 
> I am trying to understand the intended scope of the "implied *LWS"
> rule in RFC 2616.
> 
>    implied *LWS
>       The grammar described by this specification is word-based. Except
>       where noted otherwise, linear white space (LWS) can be included
>       between any two adjacent words (token or quoted-string), and
>       between adjacent words and separators, without changing the
>       interpretation of a field.
> 
> It is not clear to me whether the above wording implies that word is
> token or quoted-string and not literal. Here are two specific examples
> to illustrate the confusion.
> 
> 
>    message-header = field-name ":" [ field-value ]
>    field-name     = token
>    Authorization  = "Authorization" ":" credentials
> 
> Can one use implied LWS rule to write:
> 
> 	Authorization    : scheme param=value
> 
> and expect compliant agents to honor the Authorization header?

Yes.

> Is the Authorization field name a token or a literal?

Sect. 4.2 gives the general form of message-header.  Later sections 
provide specific values for field-name and the syntax for the rest of 
the header.  So "Authorization" is a literal, but it is also a token in 
the context of Sect. 4.2.  LWS is allowed, as per your example.

> 
> 
> Moreover,
> 
> 	Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
> 	HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
> 
> Can one use implied LWS rule to write:
> 
> 	GET / HTTP /     1   .   0
> 
> and expect compliant agents to parse the version part correctly?

My suspicion is no, although especially lenient ones might.  (Well, the 
server I wrote *wasn't* lenient. :-)

Dave Kristol

Received on Friday, 21 February 2003 17:34:14 UTC