Code

Opened 6 years ago

Closed 6 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: UI/UX:

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.

Attachments (0)

Change History (4)

comment:1 Changed 6 years ago by esaj

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 6 years ago by PJCrosier

  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 Changed 6 years ago by mattmcc

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 6 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from new to 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).

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.