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

Roy Fielding writes:
 > 
 > Instead of "intermediaries", we could say "recipients", and the following
 > paragraph:
 >  
 >    Pragma directives do not apply to the end-points of a 
 >    request/response chain. For example, a user agent's internal (non-
 >    shared) cache and/or history mechanism should ignore all pragma 
 >    directives in received messages. Similarly, pragma directives are 
 >    not applicable to the origin of a resource, though they may be 
 >    applicable to a server's internal response cache.
 > 
 > could be replaced with
 > 
 >    Pragma directives only apply to recipients that implement features
 >    corresponding to the directive's semantics.  For example, a no-cache
 >    directive tells the recipient not to make use of its caching mechanism
 >    in satisfying the request when it occurs in a request header, or in
 >    storing the response when it occurs in a response.  Pragma directives
 >    are also unidirectional in that the presence of a directive in a
 >    request does not imply that the same directive be given in the response.
 > 

I agree; it seems more robust (and useful) to include end-points in
the set that can be affected by pragma directives.  If you don't, half
the implementations are going to get it wrong anyway.

 > We can then add a new directive to cover the semantics of a response
 > that must not be shared by multiple users.  We could call it "private",
 > but I am afraid that this would also imply privacy, which it shouldn't.
 > Unfortunately, there does not seem to be an antonym for "shared" or
 > "communal", so how about
 > 
 >    Pragma: non-shared
 >            no-sharing
 >            do-not-share
 > 
 > Er, on second thought, maybe we should just use "private"...
 > 

How about Pragma: for-your-eyes-only?   

Anyhow, what you suggest seems good, because it not only allows for
private documents (without ugly URL mangling schemes), but it also
allows for something else that Koen and I were trying to accomplish
with our report on the Expires header
(http://www.amazon.com/expires-report.{html,txt}) which is to provide
for a way that history functions *could* cause automatic reloading of
a document.  With your new proposed pragma semantics, and the way it
has been interpreted already by Lou Montulli in Netscape, this would
then be enabled, and the Netscape changes mentioned could be
"rehabilitated" (to borrow a political term).  My earlier objections
to that were based on a value judgment that being able to direct a
document to one client only was considerably more valuable than being
able to have history commands invoke reloading.  But if we can have
both, lets!  I suppose it is still open to interpretation whether
pragma: no-cache is to be interpreted to preclude history mechanisms
(as opposed to caches) from storing documents, but I see no other use
for it at the client end (given the existence of Expires), so why not?

 > 
 >  ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
 >                       Visiting Scholar, MIT/LCS + World-Wide Web Consortium
 >                       (fielding@w3.org)                (fielding@ics.uci.edu)

--Shel Kaphan

Received on Wednesday, 16 August 1995 13:35:04 UTC