[issue1401] urllib2 302 POST

RuixiaZhang added the comment: I am using python 2.7,the same ,come to 302 lost cookies, I try add the code : req.headers.pop('content-length') to urllib2.py:536 but, have another error: KeyError: 'content-length' So, I want to ask is there any better method to solver this error? -- com

[issue1401] urllib2 302 POST

John J Lee <[EMAIL PROTECTED]> added the comment: I think this was actually not a bug, and the fix should not have been applied. I guess this comment is just "for the record", as the fix is probably cruft that can't be removed now, since people will have started relying on it. The only way that

[issue1401] urllib2 302 POST

Facundo Batista added the comment: Fixed in r60648, in the trunk. Now the content-length and content-type headers are removed from from the headers in the redirection. Thank you all! -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PRO

[issue1401] urllib2 302 POST

Antoine Pitrou added the comment: Content-Type is probably meaningless but harmless as well. I'd say the priority is in getting rid of headers whose misinterpretation can be annoying, such as Content-Length. __ Tracker <[EMAIL PROTECTED]>

[issue1401] urllib2 302 POST

Facundo Batista added the comment: So, the general agreement is that: - After receiven the 302, it's ok to generate a GET request. - There's a problem with the generated GET request (there should not be a Content-Length field in the headers) Right? If this is ok, I'll fix it. But, what other

[issue1401] urllib2 302 POST

Changes by Johann Tonsing: -- nosy: +jtonsing __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue1401] urllib2 302 POST

Antoine Pitrou added the comment: Hi, Sending a 302 in response to a POST is a very common practice so that the browser is redirected to a "normal", non state-changing page after the POST request has been processed. It is useful in that it allows the user to reload the resulting page (fetched wi

[issue1401] urllib2 302 POST

Jim Jewett added the comment: > But you said that #2 solution was more RFC compliant... > Could you please quote the RFC part that describes this behaviour? RFD2616 http://www.faqs.org/rfcs/rfc2616.html section 4.3 Message Body ... The presence of a message-body in a request is signaled by

[issue1401] urllib2 302 POST

Andres Riancho added the comment: As I said in my original bug report, if you don't remove the content-length header or add the data, you are sending an invalid request: START Request= GET http://f00/1.php HTTP/1.1 Content-length: 63 Accept-encoding: identity Accept: */* User-agent: w3af

[issue1401] urllib2 302 POST

Senthil added the comment: Hello Andres, I think we are mixing up 2 or 3 things. Here are my comments. 1) urllib2 POST issue. - Discussion broke on this. No conclusion. 2) GET Request. >> If we create a GET request (handling 302 as 303) we should >> remove the content length header! I fail to

[issue1401] urllib2 302 POST

Andres Riancho added the comment: According to the RFC: If urllib2 gets a 302 in response to a request, it MUST send the *same* request to the URI specified in the Location header, without modifying the method, headers, or any data (urllib2 is not RFC compliant here) In urllib2, a 301 and a 307

[issue1401] urllib2 302 POST

Facundo Batista added the comment: So, for 302 error we should resend the request as POST (header with lenght and data), and for the others we need to keep current behaviour. Actually, we just need to code a new handling function for 302, and leave the existing one as is. What do you think? __

[issue1401] urllib2 302 POST

Andres Riancho added the comment: 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

[issue1401] urllib2 302 POST

Senthil added the comment: I agree with facundobatista here. 1) I am not sure, if what you mention that doing POST in the 302 redirect url does not carry forward the POST data. Some examples would help to verify that and if this is case, IMO its a bug in urllib2. 2) You mention solution 1 as RFC

[issue1401] urllib2 302 POST

Facundo Batista added the comment: I don't understand why after receiving a redirection, and going to a new URL, you say to NOT send the POST data. Shouldn't the HTTP request be exactly like the original one, but to another URL destination? But you said that #2 solution was more RFC compliant...

[issue1401] urllib2 302 POST

Changes by Andres Riancho: -- title: urllib 302 POST -> urllib2 302 POST __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Un