- From: Shel Kaphan <sjk@amazon.com>
- Date: Thu, 17 Aug 1995 08:52:43 -0700
- 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. --Shel
Received on Thursday, 17 August 1995 09:00:16 UTC