There seems to be a move in the HTTP world to move away from 302 redirect responses to 303 redirects. The 302 response was poorly specified in the original HTTP spec, and most browsers implemented it by doing a GET on the redirected URL even if the original request was a POST, but the spec was ambiguous, and some browsers implemented it by repeating the original request to the redirected URL. The urllib module does the latter. The HTTP/1.1 spec now recommends doing the former, and it also has two new responses, 303 to unambiguously specify a redirect that must use d GET, and 307 to specify the original intent of 302. More info is on this page, which discusses the issue from a Zope perspective (which is how I found out about this): http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Use303RedirectsByDefault and here is a nice general treatise on the subject: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html It's clear that urllib would do wise to implement a handler for the 303 response. A 307 handler would be useful too. But the big question is, should we also change the 302 handler to implement the HTTP/1.1 recommended behavior? I vaguely remember that the 302 handler used to do this and that it was "fixed", but I can't find it in the CVS log. Changing it *could* break applications, but is more likely to unbreak them, given that this is now the spec's recommendation. Opinions? Whatever we do should probably also be backported to Python 2.2.1. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4