This document:Public document·View comments·Disposition of Comments·
Nearby:Mobile Web Best Practices Working Group Other specs in this tool Mobile Web Best Practices Working Group's Issue tracker
Quick access to LC-1995 LC-1996 LC-1997 LC-1998 LC-1999 LC-2000 LC-2001 LC-2002 LC-2003 LC-2004 LC-2005 LC-2006 LC-2007 LC-2008 LC-2009 LC-2010 LC-2011 LC-2012 LC-2013 LC-2014 LC-2015 LC-2016 LC-2017 LC-2018 LC-2019 LC-2020 LC-2021 LC-2022 LC-2023 LC-2024 LC-2025 LC-2026 LC-2027 LC-2028 LC-2029 LC-2030 LC-2031 LC-2032 LC-2033 LC-2034 LC-2036 LC-2037 LC-2038 LC-2039 LC-2040 LC-2041 LC-2042 LC-2043 LC-2044 LC-2045 LC-2046 LC-2047 LC-2048 LC-2049 LC-2050 LC-2051 LC-2052 LC-2053 LC-2054 LC-2064 LC-2065 LC-2066 LC-2067 LC-2068 LC-2069 LC-2070 LC-2071 LC-2072 LC-2073 LC-2074 LC-2075 LC-2076 LC-2077 LC-2078 LC-2079 LC-2080 LC-2081 LC-2082 LC-2083 LC-2084 LC-2085 LC-2089 LC-2090 LC-2091 LC-2097
Previous: LC-2038 Next: LC-2072
4.1.5 Alteration of HTTP Header Values RFC 2616 already says a lot about this. See sec 13.5.2 for example. "The theoretical idempotency of GET requests is not always respected by servers. In order, as far as possible, to avoid mis-operation of such content, proxies should avoid issuing duplicate requests and specifically should not issue duplicate requests for comparison purposes." First of all, do you mean "safe" or "idempotent"? That you refer only to GET suggests safety, but the second sentence suggests you are referring to idempotency. So please straighten that out. Oh, and there's nothing "theoretical" about GET's safety or idempotency; it's by definition, in fact. Secondly, if the server changes something important because it received a GET request, then that's its problem. Likewise, if it changes something non-idempotently because it received a PUT request, that's also something it has to deal with. In both cases though, the request itself is idempotent (and safe with GET), so I see no merit to that advice that you offer ... unless of course the problem you refer to is pervasive which clearly isn't the case. I also wonder if most of 4.1.5 shouldn't just defer to 2616. As is, large chunks of this section (as well as others) specify a protocol which is a subset of HTTP 1.1. (see also the RFC 2119 comment above)