Re: I want have "Last-modified:" in HTTP/1.0 headers

• Mail folder: WWW Talk Oct 93-present
• Next message: Steve Waterbury: "Re: Turning off a sound that you've started"
• Previous message: Markus Stumpf: "I want a SIMPLE gateway"
• In-reply-to: Steve Putz: "Re: I want have "Last-modified:" in HTTP/1.0 headers"

From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: Re: I want have "Last-modified:" in HTTP/1.0 headers 
In-reply-to: Your message of "Fri, 12 Nov 1993 13:39:16 PST."
             <93Nov12.133922pst.2445@spoggles.parc.xerox.com> 
Date: Fri, 12 Nov 1993 17:13:20 -0500
Message-id: <6057.753142400@frilled.cs.indiana.edu>
Sender: mvanheyn@cs.indiana.edu

Thus wrote: Steve Putz
>Marc VanHeyningen <mvanheyn@cs.indiana.edu> wrote:
>> Short of having every example of a gateway coded in, how could a cache
>> server possibly tell the difference?
>> 
>> Rhetorical question.  Answer:  The Expires: header.  It's the
>> responsibility of the server to make available an indication of how
>> long that information will remain "current".
>
>Is that what we want "Exipres" to mean?   In both my examples, the
>information from the gateways does not expire or become obsolete.
>Rather I was suggesting that the likelyhood of a cache hit can be small
>because the virtual information space is so large.
>
>For example, users will rarely click on the exact same latitude and
>longitude in the map viewer, and the cost of caching the resulting GIF
>image is high.  On the other hand if someone widely publishes a URL for
>a particular map, caching makes sense.
>
>My point is that choosing caching strategies becomes more difficult as
>the information space gets richer.  The Expires: header does not really
>solve the problem.

Ok, I see more what you mean.  Presumably such information which is
large and not frequently requested (like never after the first time)
won't be cached very long by any reasonable caching strategy.

A minor optimization might be to skip caching the results of applying
the SPACEJUMP method.  For that matter, POST and CHECKIN/OUT and
pretty much any method other than GET probably shouldn't be cached,
and naturally documents requiring authorization to access shouldn't be
cached (unless the authorization is global to anyone with access to
that cache, maybe.)  That solves much of the problem.  There are still
domains (most any search in which arbitrary keywords may be specified)
in which hits are less likely; a smart cache might not cache (or
expire faster) any URL which is a search (i.e. has a ? in it.)  Hits
can still happen, though; for instance, my CS Tech Report index got a
whole lot of queries for the sample searches specified in the Mosaic
demo document, and caching those could have been a win for some
locations.

- Marc
--
Marc VanHeyningen  mvanheyn@cs.indiana.edu  MIME, RIPEM & HTTP spoken here