Django

Code

Ticket #3651 (closed: fixed)

Opened 1 year ago

Last modified 10 months ago

I18N set_language goes against the recommendations in the HTTP/1.1 specification

Reported by: Fraser Nevett <mail@nevett.org> Assigned to: nobody
Milestone: Component: Internationalization
Version: SVN Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

From Section 9.1.1 of the HTTP/1.1 specification (RFC 2616): "GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval".

In the I18N code, the set_language view allows a user to change their language preference via a GET request. This sets their preference for at least the remainder of their visit to the site, so is doing more than just retrieval.

I know after the GWA content pre-fetching issues that there was some debate (see 1, 2, 3 for a small sample) over the interpretation of the RFCs; however, I would suggest that to comply with the recommendations of the HTTP specification, this method should either:

  1. only accept POST requests, or
  2. require confirmation via a POST request if GET is used.

As the second would require an additional page, I would think the first option is preferable, despite it being a backward incompatible change.

Attachments

set_language_patch.diff (3.0 kB) - added by Fraser Nevett <mail@nevett.org> on 03/04/07 08:31:51.
Patch for "option 1" (including updates for the documentation)

Change History

03/04/07 08:31:51 changed by Fraser Nevett <mail@nevett.org>

  • attachment set_language_patch.diff added.

Patch for "option 1" (including updates for the documentation)

03/04/07 08:32:34 changed by Fraser Nevett <mail@nevett.org>

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

Note that the patch also includes Jorge Gajon's patch of #3640.

03/04/07 14:19:05 changed by Simon G. <dev@simon.net.nz>

  • stage changed from Unreviewed to Design decision needed.

03/12/07 05:28:38 changed by mtredinnick

  • stage changed from Design decision needed to Accepted.

Agree that this is a bug. It's also a backwards incomaptible change, at least for those people using the GET method to call this view at the moment. So we'll apply the fix after 0.96 is released.

08/20/07 05:36:47 changed by Simon G. <dev@simon.net.nz>

  • stage changed from Accepted to Ready for checkin.

0.96 is out, so moving back to RFC

08/20/07 05:42:44 changed by mtredinnick

  • owner changed from hugo to mtredinnick.

It's just a matter of timing on this (the ready for checkin status wasn't affecting anything). I'm trying to pick the moment to break a lot of i18n'd applications. I'm trying to roll a bunch of backwards-incompatible changes into one short period so that people don't spend their entire lives forward porting.

This is on my list and will go in when I have some other significant breakage to commit.

08/20/07 16:55:33 changed by Simon G. <dev@simon.net.nz>

As always, Malcolm, you're way ahead of me!

09/14/07 02:33:45 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

(In [6177]) Fixed #3651 -- Changed set_language_view() to require POST request is used, in accordance with the HTTP spec (it changes the user's state). Thanks, Fraser Nevett.

This is a backwards incompatible change for anybody previously using this view.

09/14/07 07:01:03 changed by Marc Fargas <telenieko@telenieko.com>

Although the ticket is already closed, I didn't spot it until now, sorry.

I just have a few questions about the banckwards incompatible change:

  • Sites like to have language links somewhere (like flags) that actually point to the GET URL to change language, they'd now require an additional page to change languages via POST.
  • At least me, on google adwords I put links using the GET thing with the &next= parameter to ensure people clicking adds see the pages on the same language they saw the ad.

Maybe there are some other cases that you need to change languages and cannot use POST, but I can only thing about those two now.

So, while being RFC compliant could we provide a "GET aware" solution? maybe checking on the view if parameters where passed via GET and then render a confirmation form for the change that submits also to the view via POST ? This option would also keep things a bit more backwards complatible for current users of the GET method (given they provide a template for the confirmation form).

Also, could a parameter be given to the GET to "skip the confirmation form" for cases like the second one I said?

The first point is what the ticket describes as Option 2, it should be easy to implement if you feel ok with it. The second idea means "allow the user/developer break RFC if he/she needs so".

What do you think of both ideas?

Add/Change #3651 (I18N set_language goes against the recommendations in the HTTP/1.1 specification)




Change Properties
Action