Opened 12 years ago

Closed 12 years ago

#6227 closed (invalid)

Make HttpResponseRedirect RFC compilant.

Reported by: Piotr Lewandowski <django@…> Owned by: nobody
Component: HTTP handling Version: master
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


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 Changed 12 years ago by Jason Davies

It also states:

      Note: Many pre-HTTP/1.1 user agents do not understand the 303
      status. When interoperability with such clients is a concern, the
      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

It seems to me that using a 302 status code is the correct behaviour.

comment:2 Changed 12 years ago by Pete Crosier

Triage Stage: UnreviewedDesign decision needed

comment:3 Changed 12 years ago by Matt McClanahan

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 Changed 12 years ago by Malcolm Tredinnick

Resolution: invalid
Status: newclosed

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).

Note: See TracTickets for help on using tickets.
Back to Top