On 19/11/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > On Sat, 2005-11-19 at 18:16 +0000, sebb wrote: > > On 19/11/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > On Sat, 2005-11-19 at 15:44 +0000, sebb wrote: > > > > On 19/11/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > > > Hello Karl, > > > > > > > > > > Here's the relevant differences between HTTP requests generated using > > > > > 3.0rc3 and 3.0rc4 [1]. The only significant variation I can spot is > > > > > that > > > > > qop and nc attributes generated by rc4 are not enclosed in quotes. > > > > > This > > > > > change has been introduced in 3.0rc4 per bug report 36372 [2], which > > > > > was > > > > > perfectly valid in my opinion. See the original original discussion > > > > > here > > > > > > > > Bug report 36372 only refers to nc, surely, not qop? > > > > > > > > > [3]. What is actually really fishy here is that the digest challenge > > > > > > > > Note that qop is quoted. > > > > > > > > > > Hi Sebastian, > > > > > > This is how I read the spec [1] > > > > > > The qop attribute of the digest challenge must be enclosed in quotes > > > because it can have multiple comma separated values > > > > > > <quote> > > > challenge = "Digest" digest-challenge > > > ... > > > qop-options = "qop" "=" <"> 1#qop-value <"> > > > qop-value = "auth" | "auth-int" | token > > > </quote> > > > > > > Whereas the qop attribute of the digest response implies only one value > > > and therefore it does not have to be enclosed in quotes unless it > > > contains any special characters such as blanks or commas > > > > > > <quote> > > > credentials = "Digest" digest-response > > > ... > > > message-qop = "qop" "=" qop-value > > > </quote> > > > > <quote> > > qop ....... > > Note > > that this is a single token, not a quoted list of alternatives as > > in WWW- Authenticate. > > </quote> > > > > The description to me is a bit ambiguous - it does not say clearly > > whether or not the token includes quotes. > > > > Sebastian, > > I think there's no ambiguity. The syntax rules are very clearly laid out > in the HTTP spec [1] http://www.faqs.org/rfcs/rfc2616.html > > > Which further says: > > > > 3.2.2.1 Request-Digest > > > > If the "qop" value is "auth" or "auth-int": > > > > request-digest = <"> < KD ( H(A1), unq(nonce-value) > > ":" nc-value > > ":" unq(cnonce-value) > > ":" unq(qop-value) > > ":" H(A2) > > ) <"> > > > > To me, this suggests that qop-value, nonce-value and cnonce-value are > > quoted, whereas nc-value is not. > > > > I respectfully disagree. In the HTTP spec quote marks are always > designated as <">. See request-digest in the example above
I can't find qop-value defined anywhere as a quoted string, but nor can I find it defined as a non-quoted string. But why does the RFC use the unq() function on qop-value unless it is a quoted string? There are some other examples of the use of unq() - e.g. realm-value - in each case all of the operands are defined as being quoted strings. > > > We know nonce-value is a quoted string, and cnonce-value = nonce-value. > > > > == > > > > What I'm suggesting is to try quoting just the "qop" value, and see if > > that works for Karl. > > > > Then check if it all still works for the originator of bug 36372, who > > only mentioned a problem with "nonce-count" in the original bug text. > > > > Makes sense to me > > Oleg > > [1] http://www.faqs.org/rfcs/rfc2616.html > > > S. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
