On 19/11/05, sebb <[EMAIL PROTECTED]> 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. > > > > So, to me this is clearly a compliance issue with IIS (or whatever it > > is) server. I personally do not mind making DigestScheme more lenient > > provided it does not involve dragging in too much of IIS specific hacks. > > After all, one can simply implement a custom auth scheme and plug it > > into the HttpClient auth framework > > > > Cheers, > > > > Oleg > > > > [1] http://www.faqs.org/rfcs/rfc2617.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. > > 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.
Just discovered the following code (public domain): http://www-x.antd.nist.gov/proj/iptel/src/nist-sip/jain-sip/src/gov/nist/javax/sip/header/AuthenticationHeader.java The setParameter() method treats QOP, CNONCE and NONCE etc the same, and appears to quote them - nv.setQuotedValue(). S. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
