Opened 17 years ago
Closed 17 years ago
#6227 closed (invalid)
Make HttpResponseRedirect RFC compilant.
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Keywords: | rfc2616 http redirect post | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The RFC2616 states in 10.3.4 that:
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource.
HttpResponseRedirect is often used as a redirection after POST request (such case is present in tutorial).
Current code:
class HttpResponseRedirect(HttpResponse): status_code = 302
Should be:
class HttpResponseRedirect(HttpResponse): status_code = 303
Unfortunately this change is backwards-incompatible.
Change History (4)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:3 by , 17 years ago
I don't believe changing the behavior of HttpResponseRedirect is any more proper than using it for a redirect after POST, so changing it to a 303 wouldn't be right. At most, the response codes for views within Django (Admin, generic views, etc) might be changed.
For the general case, while I'm not a fan of adding more response classes, perhaps an HttpResponseSeeOther and/or some documentation discussing the issue (303 is "better", but has the caveat of ancient HTTP clients) would be worth considering.
comment:4 by , 17 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Not worth changing this. We're operating as per the note in 10.3.3 and the behaviour you quote is a SHOULD, not a MUST requirement (and we're not following it for the reasons given, so that's valid).
It also states:
It seems to me that using a 302 status code is the correct behaviour.