Re: Handling of IMS

From: Duane Wessels <wessels>
Date: Wed, 03 Jul 96 17:06:37 -0700 writes:

>Now some HTTP talk...
>is a modifier to GET, making it is a conditional
>GET of a single object.
>Pragma: no-cache
>is a modifier that this request can't be served from a cache,
>i.e. has to be handled by the source site.
>In my opinion the only way to make sure that you get the absolutely
>latest version is a combination of these two. Only IMS is allowed
>to return a possibly older object than available at the source site.

I disagree with Henrik on this a little bit. I think it is an issue
because most of the time, the cache selects the TTL, instead of
receiving an expiry time from the server.

Since the cache chooses the TTL, I think that an IMS request should
always go to the origin server. If all objects came with valid
Expires lines, then it would be different--the cache could handle
the IMS request itself because the server said these objects
are valid until a certain time.

Personally I don't like the reload button and 'no-cache' line; I think
its a bad hack. For one, you can only "reload" on text pages displayed
in the browser. It seems to be inconsistenly implemented too.

After we modify the code to keep each object's last-modified time
in VM, we can add a configurable interval for whether or not
to handle an IMS request in the cache. If the IMS-interval time
has been reached, the origin server should be checked. Otherwise
the cache can handle the request itself.

Duane W.
Received on Wed Jul 03 1996 - 17:06:38 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:34 MST