I18N set_language goes against the recommendations in the HTTP/1.1 specification
|Reported by:||Owned by:||nobody|
|Cc:||Triage Stage:||Ready for checkin|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
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:
- only accept POST requests, or
- 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.