Subject: Re: [Bug 201] LWS allowed in Coded-URL

From: Lisa Dusseault <[email-masked]>
Date: Sun, 4 Dec 2005 08:26:48 -0800

If I understand correctly, that's not the only place where RFC2616's  
LWS rules get us into trouble.

    TimeOut = "Timeout" ":" 1#TimeType
    TimeType = ("Second-" DAVTimeOutVal | "Infinite")
    DAVTimeOutVal = 1*digit

Applying the 2616 word-based grammer to those rules, we could have  
Timeout headers like

   Timeout: Second-   	        1111

   Timeout: Second-1   1   1   1

Is my understanding of 2616 BNF grammar correct?  I'm not sure if  
1*DIGIT is one token or several, so it's not entirely clear to me if  
the second example is allowed.  Certainly the intent of 2616 is not to  
allow that because values like Content-Length are defined as 1*DIGIT.

Lisa

On Dec 4, 2005, at 1:09 AM, [email-masked] wrote:

> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=201
>
> [email-masked] changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------- 
> -----
>          [email-masked][email-masked]
>
>
>
> ------- Additional Comments From [email-masked]   
> 2005-12-04 01:09 -------
> Explanation:
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1.p.11>
>
> Suggested change: state that LWS is not allowed here, just like in the
> grammar for "opaquelocktoken".
>
>
>
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Dec 2005 01:27:53 +0100

Lisa Dusseault wrote:
> 
> If I understand correctly, that's not the only place where RFC2616's LWS 
> rules get us into trouble.
> 

Yes.

>   Timeout: Second-1   1   1   1

No.

> 1*DIGIT is one token or several, so it's not entirely clear to me if the 
> second example is allowed.  Certainly the intent of 2616 is not to allow 
> that because values like Content-Length are defined as 1*DIGIT.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 5 Dec 2005 17:23:33 -0800

I think we're covered by this, from 2.2 in RFC 2616:

    Many HTTP/1.1 header field values consist of words separated by LWS
    or special characters. These special characters MUST be in a quoted
    string to be used within a parameter value (as defined in section
    3.6).

        token          = 1*<any CHAR except CTLs or separators>

and, from 2.1:

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. At least one delimiter (LWS and/or
       separators) MUST exist between any two tokens (for the definition
       of "token" below), since they would otherwise be interpreted as a
       single token.

- Jim

On Dec 4, 2005, at 8:26 AM, Lisa Dusseault wrote:

>
> If I understand correctly, that's not the only place where  
> RFC2616's LWS rules get us into trouble.
>
> 1*DIGIT is one token or several, so it's not entirely clear to me  
> if the second example is allowed.  Certainly the intent of 2616 is  
> not to allow that because values like Content-Length are defined as  
> 1*DIGIT.
>
> Lisa
>
>> --------------------------------------------------------------------- 
>> -------

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2005 20:10:06 +0100

Jim,

I think we do understand what RFC2616 says.

The question is, what are the exceptions in 2518bis that we need to 
state? If it applies to "opaquelocktoken", it also applies to 
"Coded-URL" and "Timeout", right?

Best regards, Julian

Jim Whitehead wrote:
>>> ---------------------------------------------------------------------------- 
>>>

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760