W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: If-Modified-Since and forged dated

From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 17 Aug 1995 08:52:43 -0700
Message-Id: <199508171552.IAA19956@bert.amazon.com>
To: Brian Behlendorf <brian@organic.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, masinter@parc.xerox.com
Brian Behlendorf writes:
 > On Thu, 17 Aug 1995, Shel Kaphan wrote:
 > > Of course your example is right.
 > > 
 > > The questionable area is whether it is reasonable to expect
 > > servers to set last-modified = the date of the last modification
 > > to the data that went into producing the dynamic document in question,
 > > or whether it is legit for them to say last-modified = date of production
 > > of the actual document that is transmitted.
 > Well, it's also "legit" for them to use Pragma: no-cache, so it's really 
 > up to how cache-friendly the server application developer wants to be.  
 > Like everything we've discussed here w/r/t caching....
 > > My entire argument rests on the assumption that the latter will be done.
 > Well, if the latter is being done, does the server really want the data 
 > cached anyways?  It's not getting cached now....
 > 	Brian
 > --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
 > brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Here's the chain of logic as I see it: Right now it is impractical to
depend on Expires, since the installed base of browsers doesn't
support it adequately (this is another, different topic).  But
sometimes you have to control caching.  Pragma: no-cache is even newer
and less supported than Expires, so we can't depend on that yet.  What
means exist to control caching?  One of the main ones is simply to
omit last-modified, which then triggers "don't cache" heuristics in
proxy caches.  So, in answer to your question, we don't see the
phenomenon of "last-modified: right now" much now because we don't
send last-modified headers on dynamic documents because we have to
omit it entirely to get any control of caching, which right now is in
practice an all/none choice.  After Expires is generally supported,
and history mechanisms generally ignore it as per the new spec, then
we'll want to start supporting GET-IMS to get finer control and enable
conditional cache-reloads.  At that time, the cacheability of dynamic
documents will be start to become an issue, so we have to design how
its going to work now.

If, as I hope will not become necessary, we have to generate
last-modified = now - (maximum clock drift between my server & any
cache) in order to ensure cacheability of documents we generate, let's
get that into the spec now.  My earlier argument is that this kluge
wouldn't be necessary if clients didn't interpret the last-modified
date, and so far nobody has argued cogently against that.

Received on Thursday, 17 August 1995 09:00:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC