- From: Shel Kaphan <sjk@amazon.com>
- Date: Thu, 19 Sep 1996 11:55:44 -0700 (PDT)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: Mike Meyer <mwm@contessa.phone.net>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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. --Shel
Received on Thursday, 19 September 1996 12:03:19 UTC