hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Problems accessing MapPoint web service after upgrading to 3.0 RC4
Date Sat, 19 Nov 2005 18:16:36 GMT
On 19/11/05, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Sat, 2005-11-19 at 15:44 +0000, sebb wrote:
> > On 19/11/05, Oleg Kalnichevski <olegk@apache.org> 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.

S.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message