- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 07 Feb 2012 15:47:46 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
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