Re: an idempotent idea (think it twice - see what happens)

Shel Kaphan writes:
> A true sign of thinking too much about this,  I woke up this morning
> with a couple ideas I need to write down before I forget them.
> 
> My interpretation (and I'm sure someone will correct me if I'm wrong)
> is, as I've previously said, that GET and HEAD are the only two standard
> HTTP methods that can be served from a cache.
> 
> (We must distinguish method requests that can be served from a cache from 
> results (of any method) that can be cached -- two different subjects).
> 
> My impression is that no other standard methods besides GET and HEAD
> can be served from a cache, but unless I missed it, the spec does not
> appear to explicitly state this.
> 
> We have the "Cache-control: no-cache" request header to force
> proxies to forward GET and HEAD requests.  
Oops. In http/1.0 we have Pragma: no-cache!
This can force 1.0 proxies to re-request the URL again.
I like the "Cache-control: no-cache" better, but in requests I want not
override the 1.0 protocol, and we shall use cache-control only as a
response header!
> 
> HTTP is supposed to be an extensible protocol, in the sense that new
> methods can be added.  At the moment the only safe thing for proxies
> to do is to forward any request for any new method, actually any
> method other than GET and HEAD, and only to serve GETs and HEADs
> that don't have Cache-control: no-cache (and that also meet certain other
> criteria).
Pragma: no-cache again, if we are talking about requests,
and Cache-control: private|no-cache in responses.
> What if someone someday invents an extension method for HTTP that
> could be served from a cache?  (Well, it *could* happen...)
> For that case, there would need to be a directive informing proxies
> that even though the request is not GET or HEAD, it is OK to serve the
> result from a cache.  In that case, perhaps it would be a good idea to
> put in another Cache-control directive that explicitly allows requests
> to be served from a cache.
Great idea!
For 1.0 version we can't add this of course, but it would be nice to
have it starting from 1.1. But here we are talking about (entities in)
responses!
> I was thinking of "Cache-control: cacheable", but that has two serious
> problems:  people don't agree on how to spell "cacheable" :), and the
> very word would probably confuse some implementors and they would
> decide it meant something on responses.  So, maybe 
> "Cache-control: serve-from-cache".
maybe Cache-control: cache?
> 	-------------------------------------------------
> On a slightly different topic, Koen Holtman also recently responded recently:
>   [ me: ]	
>   >  Expiration dates are a very weird concept anyway.
Expiration dates are very weird only when we don't have "natural"
expiration dates. For example, a 4 hour expiration of http mailing-list
hypermail archives is a clear and natural one, once the mail-html converter
runs every 4 hour. (But we have very few similar cases, when the expiration
is so natural. NOTE: Shel 'reserved' the Location header as a key for
future implementation of event-driven expiration, when the expires: date
concept can't fit the nature of a concrete resource.)
>   >We're mostly using them to signal that something is "pre-expired" and
>   >so uncacheable, something best done with some other mechanism anyway.
>
>   Well, we have Cache-Control now, which seems to be completely
>   equivalent to Expires, so you can use that.
> 
> I bring this up since I believe there's an issue that was left
> hanging.  I do not believe we have decided that Cache-control:
> no-cache is exactly equivalent to Expires: yesterday.  The difference
> is that Expires is expressly not supposed to affect history mechanisms
> ("document stacks"), whereas at least Netscape's implementation of
> Cache-control: no-cache will affect them, according to Lou Montulli.
Not yet, as I understood Lou's words.
> And Cache-control: private is certainly not equivalent to Expires:
> <future-date>, since the only effective caching that can happen with
> this directive is in the client.  
> 
> Can this please be resolved unambiguously?  I would like to see it
> specified that Cache-control: no-cache either must or must not affect
> history mechanisms as well as caches.  As we already have Expires:
> yesterday to cause one effect, I suggest we use the directive for the
> other effect.
> In any case, I repeat that using Expires: yesterday for this type of
> thing seems somewhat twisted to me. We're stuck with it at least for
> backward compatibility, but the semantics it has acquired seems
> overloaded.  Another directive would be better.
But the Expires: <yesterday> doesn't mean, that the entity-body in the
response isn't cacheable, as John Franks <john@math.nwu.edu> on 16th Aug wrote: 
"There are also reasons that a request not to cache should be orthogonal to
the Expires: header." (And I haven't see any arguments, disproving
this statement.)

The "Expires" header affects cache fetch actions,
while the "Cache-control" header affects cache store actions!

but:
The meaning of expires is not enough clear now:
For a request after the expiry time of a response the client (and intervening
proxies) shall issue a conditional (maybe unconditional, too) GET toward the
origin server.
If the response contains a new entity-body, that replaces the previous one.
If the response doesn't contain a new entity body:
1) it may contain a new expiry time, which is an update (replacement)
for the previous one.
2) may contain the same expiry time,
and we don't know, what happened. (update in progress?, update postponed? )
3) may not contain an expiry time. Unspecified again. Is it a violation of the
protocol?  Means cancellation of the original expires header?

The original words from the draft-v11-00a:
"8.13  Expires
The Expires field gives the date/time after which the entity should be 
onsidered stale. This allows information providers to suggest the
volatility of the resource. Caching clients, including proxies, must
not cache this copy of the resource beyond the date given, unless its
status has been updated by a later check of the origin server."

This words can mean, that in case 2 the cache manager should
discard the cached entity, but this will lead to the following
scenario:
conditional GET, discard old, unconditional GET, serve to the client
(the last is only for proxies).
If this situation (no change in expiry time) lasts longly we will
lost only in using proxy caches, and will lost many time if we employ
cascaded proxies.
I guess (hope), the original intention of the author (Roy) isn't that.

We can think about client caches a bit, especially on relation of
Cache-control: no-cache and history mechanism.
May be we need two directives? (differring in their relation to history
mechanism) I'm still thinking, and have no answer...

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Monday, 4 September 1995 18:37:28 UTC