This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author orsenthil
Recipients ajaksu2, akuchling, crocowhile, jimjjewett, jjlee, kxroberto, orsenthil
Date 2009-08-20.14:50:48
SpamBayes Score 4.7517268e-11
Marked as misclassified No
Message-id <1250779851.03.0.301472701483.issue1424148@psf.upfronthosting.co.za>
In-reply-to
Content
I agree with John on this ticket. At the outset, this is Not a bug.
And reading through the referenced ticket indicates the design decision
for the behavior.
In summary:
<quote>
This suggests to me that *no* automatic repeat of POST
requests should ever be done, and that in the case of a 302
or 303 response, a POST should be replaced by a GET; this
may also be done for a 301 response -- even though the
standard calls that an error, it admits that it is done by
old clients.
</quote>
That was Guido's point at that time.

The least that could be done is take a call on 301 response, but this
would break the other clients which rely on 'earlier standard behavior
though not compliant with RFC'. 

At the moment, this wont be necessary as it just break clients using
urllib. 

Giorgio's point in rekindling this issue, is not related to urllib
module and specifically w.r.t to redirect_request implementation. So, an
alternate behavior is desired on urllib2's redirects (if they are
observed by existing clients), it could be handled by another request.

So, effectively closing this request.
History
Date User Action Args
2009-08-20 14:50:51orsenthilsetrecipients: + orsenthil, akuchling, jjlee, jimjjewett, kxroberto, ajaksu2, crocowhile
2009-08-20 14:50:51orsenthilsetmessageid: <1250779851.03.0.301472701483.issue1424148@psf.upfronthosting.co.za>
2009-08-20 14:50:49orsenthillinkissue1424148 messages
2009-08-20 14:50:49orsenthilcreate