W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995


From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 31 Aug 1995 14:31:43 -0700
Message-Id: <199508312131.OAA29773@bert.amazon.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC