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 andresriancho
Recipients andresriancho, facundobatista, orsenthil
Date 2007-11-08.12:52:15
SpamBayes Score 0.1008445
Marked as misclassified No
Message-id <1194526338.04.0.289626486842.issue1401@psf.upfronthosting.co.za>
In-reply-to
Content
As mentioned in the RFC, and quoted by orsenthil, "however, most
existing user agent implementations treat 302 as if it were a 303
response", which is true for urllib2.py too ( see line 585 ):

    http_error_301 = http_error_303 = http_error_307 = http_error_302

Which means: "all redirections are treated the same way". So, if we want
to strictly respect the RFC, we should implement 4 different methods:

   - http_error_301
   - http_error_303
   - http_error_307
   - http_error_302

But urllib2 is implementing the RFC "the easy way", this is: "threat all
redirections the same, threat them as 303". 303 redirections perform a
GET on the URI, which urllib2 does here:

            return Request(newurl,
                           headers=req.headers,
                           origin_req_host=req.get_origin_req_host(),
                           unverifiable=True)

These line does not clone the old request completely, it creates a GET
request. If we create a GET request (handling 302 as 303) we should
remove the content length header!
History
Date User Action Args
2007-11-08 12:52:18andresrianchosetspambayes_score: 0.100845 -> 0.1008445
recipients: + andresriancho, facundobatista, orsenthil
2007-11-08 12:52:18andresrianchosetspambayes_score: 0.100845 -> 0.100845
messageid: <1194526338.04.0.289626486842.issue1401@psf.upfronthosting.co.za>
2007-11-08 12:52:17andresriancholinkissue1401 messages
2007-11-08 12:52:16andresrianchocreate