When using a proxy to request URLs that require Digest Auth, a header similar to the following is sent to the server: Authorization: Digest ... uri="http://example.org/foobar/spam" ... The server then responded with: HTTP/1.1 400 Bad Request Server: Microsoft-IIS/6.0 When not using a proxy, the header sent will look like: Authorization: Digest ... uri="/foobar/spam" ... and the server responded as expected with a 200 OK. I don't know what is at fault here, urllib2 or IIS, but patching the urllib2 to not use the full URL, when creating the Digest Auth. header, works. When a proxy is being used by urllib2, the Request's get_selector() will always return the full URL instead of just the selector. The code that creates the Digest auth. header also uses the get_selector() to set the "uri="-part in the auth header. Making sure that the "uri="-part is not a full URL all seems to work. See the patched urllib2.py attached. I have only tested the fix against the server I had problems with, and it seems to be working.
jan.kollhof, thanks for the report and your work on this ticket! The format of the client response to a server's digest challenge is detailed in RFC 2617, section 3.2.2: The Authorization Request Header. The urllib2.py attachment is unfortunately the whole file and not a diff, but I think from the transcript in that Jan is discussing the format of the digest-uri header. That field is in turn defined in RFC 2616, section 5.1.2: Request-URI. Request-URI = "*" | absoluteURI
abs_path
authority The absoluteURI form is REQUIRED when the request is being made to a proxy. So I believe urllib2 has the correct, RFC-conforming behavior here by sending the full URI through a proxy, and the issue is with IIS. Thus, I recommend that we close this ticket as invalid.
Yes, RFC specifically states that "The absoluteURI form is REQUIRED when the request is being made to a proxy." Thanks Jessica for making a note of that. Closing this issue as Invalid.
