This issue is not a bug, and should be closed.  It was discussed at 
length many years ago (different bug tracker ticket), and resolved.  
Since then the same issue seems to come up every year or so, 
apparently raised by people who haven't checked the issue tracker for 
previous discussion.  Please, somebody close this issue!


> It seems to be an old one.
> urllib2 still claim (as of python 2.6) the following;
> 
> # Strictly (according to RFC 2616), 301 or 302 in response
> # to a POST MUST NOT cause a redirection without confirmation
> # from the user (of urllib2, in this case).  In practice,
> # essentially all clients do redirect in this case, so we
> # do the same.

Note that this is NOT a statement about whether the request sent as a 
result of the redirect response contains the original POST data.


> This is just not true, we don't do the same at all. redirect_request
> does not pass data along and it even changes the headers to reflect
> content-size, thus behaving perfectly in accordance with RFC.

This appears to be a statement about (amongst other things) whether 
the request sent as a result of the redirect response contains the 
original POST data.

So where's the connection between the comment you quote and your 
response to it, Giorgio?  Actually, I hope you don't mind if I ask you 
not to answer that question, but instead to go and read, very 
carefully, the tracker discussion for the original fix that introduced 
the comment you posted (you should be able to find it by svn 
annotating the source, finding the appropriate commit, then looking 
for a reference in the commit message to a bug tracker issue ID).  
Once you've done that, please stop posting on this issue <0.2 wink>

Sorry, I'm not normally this grumpy, but this issue just seems to keep 
coming back forever, because people haven't spent the time to test 
browser behaviour, carefully read the RFC, tracker discussion, commit 
messages, etc.  If you have done all that and thought carefully and 
still think there's a bug, by all means come back, but please make 
sure you're extremely clear about *exactly* what you think is wrong, 
and why.  Write a test case, and cite specific RFC wording.  If what 
you think is wrong is not the same as the original issue described in 
the opening comment of this bug tracker ticket, please raise a new 
ticket rather than commenting on this one.


> For those who stumbled upon this page looking for a workaround, this 
is
> how to do: create a new class inheriting from HTTPRedirectHandler 
and
> use this one instead:

I don't know what this is a workaround *for*.