I18N set_language goes against the recommendations in the HTTP/1.1 specification
|Reported by:||Fraser Nevett <mail@…>||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.
Change History (10)
Changed 9 years ago by Fraser Nevett <mail@…>
comment:1 Changed 9 years ago by Fraser Nevett <mail@…>
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
comment:2 Changed 9 years ago by Simon G. <dev@…>
- Triage Stage changed from Unreviewed to Design decision needed
comment:3 Changed 9 years ago by mtredinnick
- Triage Stage changed from Design decision needed to Accepted
comment:4 Changed 8 years ago by Simon G. <dev@…>
- Triage Stage changed from Accepted to Ready for checkin
comment:7 Changed 8 years ago by mtredinnick
- Resolution set to fixed
- Status changed from new to closed