- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 30 Apr 2013 12:40:01 +1000
- To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Ben, I think you have it right, so have created an editorial ticket: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/474 If the editors have a problem with it, they can come back and talk to us. Cheers, On 30/04/2013, at 4:55 AM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote: > Hi, > > In sections 2.1 & 4.4 (and by reference 4.2) of p7 User Agents are guided to take "special care" when parsing WWW-Authenticate and/or Proxy-Authenticate header field values, but it is never plainly stated what that means. > > From the grammar, it looks as if the critical distinction is that (ignoring any allowed whitespace for brevity): > > A sequence "," token "=" means we are now receiving a parameter to an existing challenge. This is guaranteed because the "=" and value are non-optional components of auth-param. (The grammar would be unresolvably ambiguous otherwise.) > > A sequence "," token and anything other than "=" means we are now receiving the start of a new challenge. This is guaranteed because token68 may not contain "," and token (for a following auth-param) may not be empty. (The grammar would be unresolvably ambiguous otherwise.) > > (And if we don't get something, after whitespace elimination, which is either the end of the header field value or a token after the ",", then the value is invalid and should be rejected.) > > If that interpretation is correct, it would be helpful to state this clearly, rather than merely infer it. (And if that interpretation is not correct, clearly relying on inference alone is unreliable!) > > There is perhaps still the question of whether in the face of multiple WWW/Proxy-Authenticate headers, the implied "," separating their values according to #rule is still allowed to operate at both levels of the grammar, or only at the outermost (#challenge) level. > > Thanks > Ben > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 30 April 2013 02:40:29 UTC