#287: LWS in auth-param ABNF

Hi.

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/287>:

-- snip --
I believe the ABNF for auth parameters

   auth-scheme    = token
   auth-param     = token "=" ( token / quoted-string )

needs to allow OWS around "=".
-- snip --

So RFC 2617 
(<http://greenbytes.de/tech/webdav/rfc2617.html#rfc.section.1.2>) had:

-- snip --
    auth-param     = token "=" ( token | quoted-string )
-- snip --

But RFC 2617 uses the RFC 2616 ABNF rules, allowing implied LWS 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1.p.11>):

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

...and RFC 2617 doesn't say otherwise.

Looking at UA behavior 
(<http://greenbytes.de/tech/tc/httpauth/#simplebasicwsrealm>):

- IE, Safari, and Chrome accept it

- Firefox, Opera, and Konqueror do not

I checked the Firefox source, and it just does a string-search for 
"realm="; so this code is broken anyway (as seen in other test cases), 
and will need a major rewrite.

The Konqueror devs are aware of the problem, and I think are waiting for 
us to resolve the issue.

Safari: dunno.

Proposal:

Add *BWS* (not *OWS*) around "=". BWS is specified in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-15.html#rfc.section.1.2.2> 
as:

-- snip --
BWS is used where the grammar allows optional whitespace for historical 
reasons but senders SHOULD NOT produce it in messages. HTTP/1.1 
recipients MUST accept such bad optional whitespace and remove it before 
interpreting the field value or forwarding the message downstream.
-- snip --

which I believe is exactly right (and something we may want to use in 
other cases where we have parameter-like constructs).

Feedback appreciated,

Julian

Received on Saturday, 6 August 2011 11:08:36 UTC