Make HttpResponseRedirect RFC compilant.

[Piotr Lewandowski <django@…>]

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.

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

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

[Malcolm Tredinnick]

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