#342 WWW-Authenticate ABNF slightly ambiguous

Hi there,

sometime ago, when writing the tests at 
<http://greenbytes.de/tech/tc/httpauth/>, I noticed that the grammar for 
WWW-Authenticate (and Proxy-Authenticate) is ambiguous:

Example:

  Basic realm="foo", , Otherscheme realm="bar"

This can be parsed as either three challenges:

1: Basic realm="foo"
2:
3: Otherscheme realm="bar"

or as two challenges:

1: Basic realm="foo",
2: Otherscheme realm="bar"

...where the first challenge has a list of auth-params where the first 
one is the realm, and the second one is empty.

(see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/342>).

Proposal: just note this so implementers aren't more surprised than needed.

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/342/342.diff>

This changes the text for *Authenticate to:

4.2.  Proxy-Authenticate

    The "Proxy-Authenticate" header field consists of a challenge that
    indicates the authentication scheme and parameters applicable to the
    proxy for this effective request URI (Section 4.3 of [Part1]).  It
    MUST be included as part of a 407 (Proxy Authentication Required)
    response.

      Proxy-Authenticate = 1#challenge

    Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
    only to the current connection and SHOULD NOT be passed on to
    downstream clients.  However, an intermediate proxy might need to
    obtain its own credentials by requesting them from the downstream
    client, which in some circumstances will appear as if the proxy is
    forwarding the Proxy-Authenticate header field.

    Note that the parsing considerations for WWW-Authenticate apply to
    this header field as well; see Section 4.4 for details.


and


4.4.  WWW-Authenticate

    The "WWW-Authenticate" header field consists of at least one
    challenge that indicates the authentication scheme(s) and parameters
    applicable to the effective request URI (Section 4.3 of [Part1]).

    It MUST be included in 401 (Unauthorized) response messages and MAY
    be included in other response messages to indicate that supplying
    credentials (or different credentials) might affect the response.

      WWW-Authenticate = 1#challenge

    User agents are advised to take special care in parsing the WWW-
    Authenticate field value as it might contain more than one challenge,
    or if more than one WWW-Authenticate header field is provided, the
    contents of a challenge itself can contain a comma-separated list of
    authentication parameters.

    For instance:

      WWW-Authenticate: Newauth realm="apps", type=1,
                        title="Login to \"apps\"", Basic realm="simple"

    This header field contains two challenges; one for the "Newauth"
    scheme with a realm value of "apps", and two additional parameters
    "type" and "title", and another one for the "Basic" scheme with a
    realm value of "simple".

       Note: the challenge grammar production uses the list syntax as
       well.  Therefore, a sequence of comma, whitespace, and comma can
       be considered both as applying to the preceding challenge, or to
       be an empty entry in the list of challenges.  In practice, this
       ambiguity does not affect the semantics of the header field value
       and thus is harmless.


Feedback appreciated, Julian

Received on Tuesday, 7 February 2012 14:51:07 UTC