urllib2 Digest Authorization uri must match request URI

@orsenthil

BPO	8843
Nosy	@orsenthil
Files	urllib2.diff: Patch against urllib2

^{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 2010-05-28.11:33:17.694>
labels = ['type-bug', 'library']
title = 'urllib2 Digest Authorization uri must match request URI'
updated_at = <Date 2019-03-15.23:05:29.023>
user = 'https://bugs.python.org/anelis'

bugs.python.org fields:

activity = <Date 2019-03-15.23:05:29.023>
actor = 'BreamoreBoy'
assignee = 'orsenthil'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2010-05-28.11:33:17.694>
creator = 'anelis'
dependencies = []
files = ['17480']
hgrepos = []
issue_num = 8843
keywords = ['patch']
message_count = 3.0
messages = ['106649', '223116', '223413']
nosy_count = 2.0
nosy_names = ['orsenthil', 'anelis']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8843'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

Linked PRs

When using Digest authentication to authenticate with a web server, according to rfc2617 (section 3.2.2.5) the uri in the Authorization header MUST match the request URI.

urllib2.AbstractDigestAuthHandler doesn't honour this when we request a url of the form 'http://hostname' without the trailing slash and we end up with request headers of the form:

GET / 1.1
...
Authorization: Digest ... uri="" <- should be uri="/"!

A web server will return 400 Bad Request error.

I attach a patch to fix urllib2.AbstractDigestAuthHandler.get_authorization that simply checks for the empty uri and uses '/' instead. It's the same thing that httplib.HTTPConnection does when it builds the GET line.

However I do wonder if this uri normalisation should be part of Request.get_selector?

Following is a script to demonstrate the behaviour, if you call it as:

./do_digest_request.py http://myserver username password

(and assuming myserver is using Digest authentication) there will a 400 response instead of it working.

--- do_digest_request.py
#!/usr/bin/env python

import sys
import urllib2
import urlparse

def request( url, username, password ):

    p = urlparse.urlparse( url )
    password_manager = urllib2.HTTPPasswordMgrWithDefaultRealm()
    password_manager.add_password( None, p.hostname, username, password )

    handlers = [
        urllib2.HTTPDigestAuthHandler( password_manager ),
    ]

    opener = urllib2.build_opener( *handlers )
    request = urllib2.Request( url )
    response = opener.open( request )
    response.read()


if __name__ == '__main__':
    request( sys.argv[1], sys.argv[2], sys.argv[3] )

@andrew

@andrew we're sorry about the delay in getting back to you. @senthil can you comment on this please.

FWIW, here's my take on this:

RFC 2617 (3.2.2.5) states: This may be "*", an "absoluteURL" or an "abs_path" as specified in section 5.1.2 of [2], but it MUST agree with the Request-URI.

Note: It must AGREE.

RFC 3986 (6.2.3) states: In general, a URI that uses the generic syntax for authority with an empty path should be normalized to a path of "/".

In my mind, this normalization should actually happen server-side, not client as the patch is suggesting.

Additionally, should the logic in the supplied patch be applied, it would be inconsistent with any other than an empty path:

http://example.com -> /
http://example.com/foo -> /foo

I would close this as won't fix.

Side note: get_selector was deprecated in 3.3 and removed in 3.4 in favour of the Request.selector attribute.

Given the 10 years without changes and the opinion above that it should be a won't-fix,, this issue will be closed unless someone opposes that and gives feedback .

I have explained it in #161009 on why this is a bug. This is an internal inconsistency within urllib. For empty selectors "", the http.client sets the selector as / while the digest authentication sets it as "", thereby failing the authentication either as URI mismatch or as a hash mismatch.

This is client side bug (long pending in urllib) and I have the PR to fix it.

gh-53089: Send uri="/" in Digest auth for URLs with an empty path (#1…

[3.14] gh-53089: Send uri="/" in Digest auth for URLs with an empty p…

[3.15] gh-53089: Send uri="/" in Digest auth for URLs with an empty p…

Navigation Menu

urllib2 Digest Authorization uri must match request URI #53089

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

urllib2 Digest Authorization uri must match request URI #53089

Description

Linked PRs

Activity

anelis commented on May 28, 2010

BreamoreBoy commented on Jul 15, 2014

demianbrecht commented on Jul 18, 2014

devdanzin commented on Sep 21, 2025

orsenthil commented on Oct 31, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions