[issue1401] urllib 302 POST
Andres Riancho
report at bugs.python.org
Wed Nov 7 22:42:59 CET 2007
New submission from Andres Riancho:
There is an error in urllib2 when doing a POST request to a URI that
responds with a 302 redirection. The problem is in urllib2.py:536, where
the HTTPRedirectHandler creates the new Request based on the original one:
newurl = newurl.replace(' ', '%20')
return Request(newurl,
headers=req.headers,
origin_req_host=req.get_origin_req_host(),
unverifiable=True)
The issue is that when it creates the new request, it uses the old
headers (which contain a content-length header, remember that we
originally sent a POST!) but doesn't use the same post-data from the
original request (in fact it doesn't use any post-data). So, when the
new request is sent, urllib2 sends something like:
====START Request=====
GET http://f00/1.php HTTP/1.1
Content-length: 63
Accept-encoding: identity
Accept: */*
User-agent: w3af.sourceforge.net
Host: f00
Content-type: application/x-www-form-urlencoded
==== END REQUEST ===
The server waits some time for the post-data that is advertised in
"Content-length: 63" but it never arrives, so the connection is closed
and urllib2 timeouts.
There are two different solutions to this issue, implementing one is
enough to solve it:
1) when creating the new request, remove the content length header
2) when creating the new request, add the post-data of the old request
I think that the solution 1) is the most RFC-compliant solution. I coded
a small patch for urllib2.py of python2.5 that solves this issue, the
patch simply adds a line that removes the cl header:
newurl = newurl.replace(' ', '%20')
req.headers.pop('content-length')
return Request(newurl,
headers=req.headers,
origin_req_host=req.get_origin_req_host(),
unverifiable=True)
----------
components: None
messages: 57223
nosy: andresriancho
severity: minor
status: open
title: urllib 302 POST
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1401>
__________________________________
More information about the Python-bugs-list
mailing list