RE: Problem with authentication challenge BNF and Digest

My very strong hunch is that proposal two is not backwards compatible
with existing implementations of Digest Auth. Originally, I believe that
only one challenge was permitted per WWW-Authenticate header; the
ability to have several was added later. 

>----------
>From: 	Henrik Frystyk Nielsen[SMTP:frystyk@w3.org]
>Sent: 	Friday, July 05, 1996 3:35 PM
>To: 	john@math.nwu.edu; fielding@w3.org; jg@w3.org
>Cc: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Problem with authentication challenge BNF and Digest
>
>
>As far as I know this has not been mentioned on the list...
>
>While writing the parser for the access authentication challenge
>parser, it 
>became clear that it is almost impossible to distinguish the auth-param
>from 
>a new challenge (there may be multiple challenges separated by comma).
>
>According to the latest Digest Authentication draft from John Franks
>the 
>described syntax for the WWW-authenticate header doesn't contain a
>comma at 
>all (however, it does include them in the examples in Section 2.4).
>Hence 
>the two versions are in conflict and digest is in internal conflict.
>Another 
>problem is that the challenge BNF requires a single space between the 
>auth-scheme and the realm and digest doesn't. 

I don't see this in the Digest draft. It says
     WWW-Authenticate    = "WWW-Authenticate" ":" "Digest"
                              digest-challenge

     digest-challenge    = 1#( realm | [ domain ] | nonce |
                          [ digest-opaque ] |[ stale ] | [ algorithm ] )

The parameters in "digest-challenge" _are_ comma separated, because of
the "1#" at the beginning. The HTTP draft requires 1*SP between the
scheme name and its params, whereas the digest draft allows any LWS (by
default). I'll bet that almost all implementations allow LWS in
WWW-Authenticate despite what the HTTP spec says -- my lexer, for
example, always skips LWS.

Also, the rules for combining multiple instances of headers of the same
name together require that a comma be inserted between the value fields
of each header. This, plus backwards compatibility mean, I'm afraid,
that we'll just have to live with the near ambiguity. It isn't worth
changing the HTTP spec at this point.

If you want to change the Digest spec to be clearer about the 1*SP, we
could do that when it goes to Draft Standard.

Paul
>

Received on Friday, 5 July 1996 16:22:55 UTC