- From: Shel Kaphan <sjk@amazon.com>
- Date: Thu, 31 Aug 1995 14:31:43 -0700
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
What property is it that GET and HEAD have that no other methods have? [ don't answer "idempotence"! ] One answer: they are the only methods (so far) that can be handled by an intermediate proxy other than the origin server. I think that's what should be said about them instead of calling them "idempotent", "usually side-effect free", "topology-preserving", "read-only", "always-the-same-result-producing-except-when-they-don't", or other properties. Why can GET and HEAD be served by caches? Because they conventionally have no side effects at the origin server. We say "conventionally" because some script writers might choose to violate this rule for their own nefarious purposes. They can't be stopped, so don't try. A "side effect" is a change that affects the future behavior of the server and its environment as detectable by users and user agents. So "side effects" exclude log file entries, last-accessed dates on files, etc. It's always going to be a somewhat fuzzy distinction -- after all someone could write a script that performed financial transactions based on file access dates or number of characters in a log file. No other standard HTTP methods share this property of being able to be handled by intermediate proxies. (With Pragma: no-cache this is untrue even of GET and HEAD). If GET or HEAD normally had side effects on the origin server, that would contradict their ability to be handled by caches. So there's a "convention" that they shouldn't. Isn't that all it is necessary to say about it?
Received on Thursday, 31 August 1995 15:17:05 UTC