[Patches] [ python-Patches-1479302 ] Make urllib2 digest auth and basic auth play together

SourceForge.net noreply at sourceforge.net
Sun Apr 30 15:25:10 CEST 2006


Patches item #1479302, was opened at 2006-04-30 14:15
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make urllib2 digest auth and basic auth play together

Initial Comment:
urllib2.HTTPDigestAuthHandler breaks urllib2's handler
scheme by raising an exception instead of returning
None to indicate another handler might handle the
response.  This stops everything in its tracks (the
exception is not caught by urllib2) and prevents
urllib2.HTTPBasicAuthHandler from handling basic auth
scheme 40* responses.

The patch simply removes the raise statement, so that
the .http_error_auth_reqed(), and therefore
.http_error_40*(), returns None.

There is also a unit test.

(will upload patch in a sec when I have the tracker ID
to insert in the test)

2.4 backport candidate.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2006-04-30 14:25

Message:
Logged In: YES 
user_id=261020

Just a note that an XXX comment at the top of the code
comments that:

"""
If an authentication error handler that tries to perform
authentication for some reason but fails, how should the
error be signalled?  The client needs to know the HTTP error
code.  But if the handler knows that the problem was, e.g.,
that it didn't know that hash algo that requested in the
challenge, it would be good to pass that information along
to the client, too.
"""

I think this problem should be handled using module logging,
similarly to how module cookielib logs its reasoning for
accepting and returning cookies.

Do people agree?  If so, I'll file another patch to add that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479302&group_id=5470


More information about the Patches mailing list