Found urllib strangeness with redirects - is this really a problem?

[John J Lee]

On Fri, 28 Feb 2003, Andrew Dalke wrote:

> Akai Majo Sizer
> >   Note: RFC 1945 and RFC 2068 specify that the client is not allowed
> >   to change the method on the redirected request.  However, most
> >   existing user agent implementations treat 302 as if it were a 303
> >   response, performing a GET on the Location field-value regardless
> >   of the original request method. The status codes 303 and 307 have
> >   been added for servers that wish to make unambiguously clear which
> >   kind of reaction is expected of the client.
> >
> > Is this even worth caring about? Maybe at least a comment in the code?
> > Personally, my problem is solved, but it was a bear to figure out what
> > was going on, so I thought I'd mention it.
>
> Me?  I prefer that it match the specification.  Eg, suppose I'm using urllib
> for something besides POST, like a HEAD or a DELETE or ....  I don't
> want that turned into a GET request.  A browser can get away with it because
> for most of its cases a POST and GET are the same.

I don't understand the distinction you're making there about browsers
vs. Python, Andrew.

A patch has already been submitted for the equivalent urllib2 bug. After a
long discussion (SF bug 549151), everybody agreed it was indeed a bug.
Guido agreed it should go into 2.3, but I don't think it has done... I
should consolidate everything (changes to docs and urllib.py and
urllib2.py) into one patch and try again, I suppose. The patch does allow
one to trivially subclass HTTPRedirectHandler to get a 'strict'
implementation.  IIRC urllib wasn't quite so fixable (I don't recall why
-- see the bug discussion).

If anybody wants the 'right' behaviour (taking into account the
(universal) browser behaviour and careful reading of the HTTP RFCs (in
fact the most recent HTTP RFC is 2616)), ClientCookie already does this if
you use the urllib2-like callables.


John