- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 8 Aug 2011 15:18:31 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
+1 On 06/08/2011, at 9:07 PM, Julian Reschke wrote: > 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 > -- Mark Nottingham http://www.mnot.net/
Received on Monday, 8 August 2011 05:18:58 UTC