hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Docken (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1094) HttpClient generates new cnonce on each request to server, causes issues with IIS
Date Wed, 25 May 2011 19:23:47 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039293#comment-13039293

Jesse Docken commented on HTTPCLIENT-1094:

I've attached a log of HttpClient interacting with an IIS server 3 times, slightly modified
to obfuscate sensitive information (I've modified the response hashes as well to correlate
with the new values).  The server rejects the second request, and it appears to be because
HttpClient recalculates the A1 value (it could also be due to the second CNonce value; I have
not verified this yet).  I've also attached a document comparing how HttpClient calculates
the response hash, how Internet Explorer calculates it, and how it appears to be described
in RFC 2617.  Hopefully this illustrates what I'm trying to say a bit better.

> HttpClient generates new cnonce on each request to server, causes issues with IIS
> ---------------------------------------------------------------------------------
>                 Key: HTTPCLIENT-1094
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1094
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.1.1
>         Environment: Windows Server 2008 R2 Standard Edition SP1 (64-bit Intel)
> Internet Information Services 7.5
> JRE 1.6.0_24
>            Reporter: Jesse Docken
>         Attachments: Client-Server Headers.log, Implementations.txt
> While attempting to authenticate into the local IIS server, the first request completes
successfully (in this case, it was a HEAD request).  The next request (a GET request), however,
generates a 401 error message.  Re-issuing the request allows it to succeed.
> I compared the interactions between HttpClient and the server with Internet Explorer
and Firefox and concluded that both Firefox and HttpClient generate new CNonce values on each
request sent to the server, triggering the 401 response when it sends the new CNonce.  Internet
Explorer only generates a new CNonce if the server generates a new Nonce, which would force
reauthentication anyway.  According to RFC 2617 ( A1), the A1 key for the response
is only supposed to be generated once per authentication session, which Internet Explorer
does properly.  The specification does also say that the cnonce should be uniquely generated
later in the response, which Firefox and HttpClient do, but Internet Explorer does not.
> This is somewhat messy, but the end result is this:
> First request to server: server asks for authentication
> Resend first request: generate cnonce "b8c2f608613eea3e3911e964f3983ce5", which is used
in A1 and response
> Second request to server: reuse original A1 with first cnonce, generate new cnonce "55f807fbebfbde40bba8be0cfb6e8b38"
which is used in response only
> This does seem odd, and I can't find any errata for the RFC that addresses the double-cnonce
issue.  I might also be misinterpreting the unq(cnonce) for request-digest, but it does explicitly
state in that A1 is only to be generated once per authentication session, which HttpClient
does not do.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message