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 jjlee
Recipients
Date 2002-06-23.19:23:04
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John
History
Date User Action Args
2007-08-23 14:00:59adminlinkissue549151 messages
2007-08-23 14:00:59admincreate