-
-
Notifications
You must be signed in to change notification settings - Fork 30k
-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
urllib.FancyURLopener.redirect_internal looses data on POST! #42869
Comments
def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl) ... has to become ... def redirect_internal(self, url, fp, errcode,
errmsg, headers, data):
if 'location' in headers:
newurl = headers['location']
elif 'uri' in headers:
newurl = headers['uri']
else:
return
void = fp.read()
fp.close()
# In case the server sent a relative URL, join
with original:
newurl = basejoin(self.type + ":" + url, newurl)
return self.open(newurl,data) ... i guess? ( ",data" added ) Robert |
Logged In: YES Found http://www.faqs.org/rfcs/rfc2616.html (below). urllib2 has the same bug with POST redirection. ======= The requested resource has been assigned a new permanent The new permanent URI SHOULD be given by the Location If the 301 status code is received in response to a
user agents |
Logged In: YES This is not a bug. |
Logged In: YES the analyzation of the browsers is right. lynx is best ok to gvr's initial suggestion to raise a clear error (with To redirect POST as GET _while_ simply loosing (!) the data The current behaviour is most worst of all 4. All other |
Logged In: YES In theory, a GET may be automatic, but a POST requires user Often, the page will respond to either; not sending the |
Logged In: YES First, anyone replying to this, *please* read this page (and http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html kxroberto: you say that with standard urllibX error handling It's perfectly reasonable to extend urllib (if necessary) to It would of course break backwards compatibility to start The only doubtful case here is 301. A decision was made on kxroberto.seek(nrBytes)
assert kxroberto.readline() == """\
To redirect POST as GET _while_ simply loosing (!) the data
(and not appending it to the GET-URL) is most bad for a lib.""" No. There is no value in supporting behaviour which is kxroberto: """Don't know if the MS & netscape's also urllib2's behaviour (and urllib's, I believe) on these jimjewett: """In theory, a GET may be automatic, but a POST That theory has been experimentally falsified ;-) |
Logged In: YES Sorry, I was trying to provide a quick explanation of why we Yes, I realize that in practice, GET is used for non- But since that is the official policy, I wouldn't want to |
Logged In: YES Conservative or not, I see no utility in changing the |
Can this item be closed, given jjlee's argument against changing the |
I agree that changing the default isn't an option. However, IMHO, having to override HTTPRedirectHandler.redirect_request Maybe the docs should contain an example of how to be compliant? |
I am not sure where we stand with this issue. It seems to be an old one. # Strictly (according to RFC 2616), 301 or 302 in response This is just not true, we don't do the same at all. redirect_request For those who stumbled upon this page looking for a workaround, this is class AutomaticHTTPRedirectHandler(urllib2.HTTPRedirectHandler):
def redirect_request(self, req, fp, code, msg, headers, newurl):
"""Return a Request or None in response to a redirect.
The default response in redirect_request claims not to
follow directives in RFC 2616 but in fact it does
This class does not and makes handling 302 with POST
possible
"""
m = req.get_method()
if (code in (301, 302, 303, 307) and m in ("GET", "HEAD")
or code in (301, 302, 303) and m == "POST"):
newurl = newurl.replace(' ', '%20')
return urllib2.Request(newurl,
data=req.get_data(),
headers=req.headers,
origin_req_host=req.get_origin_req_host(),
unverifiable=True)
else:
raise urllib2.HTTPError(req.get_full_url(), code, msg,
headers, fp) |
This issue is not a bug, and should be closed. It was discussed at
Note that this is NOT a statement about whether the request sent as a
This appears to be a statement about (amongst other things) whether So where's the connection between the comment you quote and your Sorry, I'm not normally this grumpy, but this issue just seems to keep
I don't know what this is a workaround *for*. |
As you can see yourself, that code does a complete redirection, taking I never said it was "bug" nor that the code had to be changed. I am just |
If you have a feature request, please open a separate ticket. This one |
I am assigning this to myself. I shall do some research on this issue + |
I agree with John on this ticket. At the outset, this is Not a bug. The least that could be done is take a call on 301 response, but this At the moment, this wont be necessary as it just break clients using Giorgio's point in rekindling this issue, is not related to urllib So, effectively closing this request. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: