Re: Expires, Last-Modified, Pragma: no-cache etc.

> 
> >But what is the difference between the Pragma: no-cache and Pragma: private?
> 
> private would mean the response is intended for a single user agent
> and thus must not be stored in a shared response cache.
> 
> no-cache would mean the response must not be stored in any response cache.
This would introduce an incompatibility between HTTP/1.0 and HTTP/1.1!
I suggest not touching the 1.0 semantics for no-cache pragma because it's
implemented in current applications, but we can add a new 'Pragma: dynamic' or
something else with the same semantics.
Pros:
There is a demand for the semantics (or better shall I name it feature?),
generated by - important in present and even more important in near future -
shopping-basket applications.
It is simpler, than the alternate solution.
Cons: (regarding Pragma: dynamic)
This will change the general semantics of the pragmas. In 1.0 pragmas have
effect only on intermediates. This isn't a big issue, because we have only
the pragma no-cache in 1.0. Leaving it untouched, we will not introduce
incompatibility really, the incompatibility will be formal only.
Alternate solution:
There is an unanswered (on this list at least) proposal by Shel Kaphan
to introduce event-driven document expiration.
Implementing evend-driven document expiration can be done in two ways:
a) outside the http protocol
This case shall be discussed not in this list, I presume, but see
URL http://morse.colorado.edu/~wessels/Proxy/Thesis/newproxy.html by 
Duane Wessels on rcached.
b) in http protocol
While servers doesn't initiate connections to clients (we can safely assume,
that they never will - or firewall implementors will kill us), this can be done
by enabling expiry notifications stuffed into response headers.
(eg, in responses to POST-ing shopping actions for shopping basket apps),
but general-purpose expiry notifications stuffed into response header of
unrelated URL-s will make caching proxies a lot more complicate.
(proxies shall interpret the expiry notifications, forward to current client,
and then store them independently of the currently requested URLs, and later
propagate it in other response headers to clients and other proxies, possibly
having stale copies.)
I don't know, it is possible within http/1.x or not.

Andrew.

Received on Thursday, 17 August 1995 18:07:12 UTC