id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 3651 I18N set_language goes against the recommendations in the HTTP/1.1 specification Fraser Nevett nobody "From [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 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 [http://webaccelerator.google.com/ GWA] content pre-fetching issues that there was some debate (see [http://www.37signals.com/svn/archives2/google_web_accelerator_hey_not_so_fast_an_alert_for_web_app_designers.php 1], [http://simonwillison.net/2005/May/6/bad/ 2], [http://shiflett.org/archive/284 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." closed Internationalization dev fixed Ready for checkin 1 0 0 0 0 0