Repository navigation
urllib2 does not correctly handle multiple www-authenticate headers in an HTTP response #57532
Description
| BPO | 13323 |
|---|---|
| Nosy | @loewis, @orsenthil, @akheron, @vadmium |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/orsenthil'
closed_at = None
created_at = <Date 2011-11-02.16:06:05.582>
labels = []
title = 'urllib2 does not correctly handle multiple\twww-authenticate headers in an HTTP response'
updated_at = <Date 2015-02-10.06:39:27.357>
user = 'https://bugs.python.org/dfischer'bugs.python.org fields:
activity = <Date 2015-02-10.06:39:27.357>
actor = 'martin.panter'
assignee = 'orsenthil'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2011-11-02.16:06:05.582>
creator = 'dfischer'
dependencies = []
files = ['23619']
hgrepos = []
issue_num = 13323
keywords = ['patch']
message_count = 10.0
messages = ['146842', '146866', '146867', '146870', '146875', '146981', '147193', '196783', '196784', '235670']
nosy_count = 7.0
nosy_names = ['loewis', 'orsenthil', 'dfischer', 'petri.lehtinen', 'martin.panter', 'Dmitry.Beransky', 'Sigmund.Augdal']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue13323'
versions = ['Python 2.7']Metadata
Metadata
Assignees
Projects
- Status
Activity
dfischer commentedon Nov 2, 2011
I ran into an application that responded with two www-authenticate challenges to an HTTP request. First, it sends a standard Basic authentication challenge and then it also returns a www-authenticate header referencing another scheme. This looks legal to me according to rfc2617.
However, the regex in AbstractBasicAuthHandler that parses the www-authenticate header only grabs one of the challenges (the last one) and therefore urllib2 will not respond to the challenge with credentials.
loewis commentedon Nov 2, 2011
What exactly do you mean by "then"? In HTTP, there is only a single
response to a single request, so in what way does the server send
two responses to a single request?
[-]urllib2 does not correctly handle multiple www-authenticate headers in an HTTP response[/-][+]urllib2 does not correctly handle multiple www-authenticate headers in an HTTP response[/+]dfischer commentedon Nov 2, 2011
Perhaps I should have chosen my words more carefully. There are two www-authenticate headers the single HTTP response.
loewis commentedon Nov 2, 2011
So what do you propose to do? RFC 2617 specifies
The user agent MUST choose to use one of the challenges with the
strongest auth-scheme it understands and request credentials from the
user based upon that challenge.
dfischer commentedon Nov 2, 2011
I think the key words in the RFC are "strongest auth-scheme it understands". I think in an ideal world, the urllib2 opener (given its handlers) would see that it doesn't understand the second auth-scheme and then see if it understands the first one. However, the term "strongest" implies an ordering among the auth schemes.
loewis commentedon Nov 3, 2011
Would you like to provide a patch?
dfischer commentedon Nov 6, 2011
With this patch, the AbstractBasicAuthHandler (and its subclasses) performs a regex search on the amalgamated "www-authenticate" header for basic authentication.
This fixes the case where you have an HTTP response of the form:
HTTP/1.1 401 Authorization Required
Server: HTTPd/1.0
WWW-Authenticate: Basic realm="Secure Area"
WWW-Authenticate: SomethingElse realm="Alternative"
...
In the above case, AbstractBasicAuthHandler will attempt basic auth against the "Secure Area" realm.
SigmundAugdal commentedon Sep 2, 2013
Can someone please apply this patch or provide a reason why it should not be applied?
orsenthil commentedon Sep 2, 2013
Sigmund: Sorry for the delay. I shall act on this.
vadmium commentedon Feb 10, 2015
bpo-15310 appears to have a more thorough patch
orsenthil commentedon Oct 28, 2026
This is handled by
AbstractBasicAuthHandler - #18284 - Completed in 2020
AbstractDigestAuthHandler - #160828 - Tracked in #59515