W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: idempotence of POST

From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 19 Sep 1996 11:55:44 -0700 (PDT)
Message-Id: <199609191855.LAA16687@iguana.amazon.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: Mike Meyer <mwm@contessa.phone.net>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1604
Jeffrey Mogul writes:
 >     I've always had a problem with the opposite problem - that GETS can be
 >     assumed to be safely reloadable.
 >     [...]
 >     So...
 >     > c) allow the return value of POST to indicate that the request
 >     >    can be repeated safely.
 >     > Is this worth pursuing?
 >     Yes, especially if the same mechanism is used to allow responses to
 >     GET requests indicate that they are NOT safely reloadable.
 > I think this would be dangerous.  HTTP/1.1 says that GETs are
 > assumed to be reloadable because this is, in fact, what most (all?)
 > existing caches assume, not necessarily because this is the best
 > way to have designed the original protocol.
 > If we were to add a mechanism to mark GET responses as non-reloadable,
 > it wouldn't do much good (at least, not for a long time) because
 > the server could never be sure that no older cache would get hold
 > of the response and ignore that mark.
 > -Jeff

It *should* be the case that if there are any cache-control headers
not recognized by a cache, the cache ought to assume the object is not
cachable.   Now, I don't have enough time right this minute to go find
out if we remembered to specify that or not.  In any case, if we
did, then any new controls for this behavior probably should go into
some new option of cache-control.
Received on Thursday, 19 September 1996 12:03:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC