Issue List: CACHEDATE

Quoted from the Issue List, Top CACHEDATE:

> If the server receives an If-Modified-Since: containing a date that is
> later than the actual modification time of the resource, should it 
> return 304 Not Modified or should it treat this as a validation
> failure? For example, if the I-M-S header says "Tue Jan 30 00:59:57
> 1996" but the resource's actual modification time is Jan 29 00:00:00
> 1996, should the server be paranoid and return the full resource, or
> should it blithely assume that the client had a good reason for
> constructing its own I-M-S date? 

I can contribute an application which causes I-M-S dates differing from
the original modification time. Assume that documents are created on the
fly by a server/CGI script using multiple other documents or some
external data. The overall modification time is computed as the latest
modification time of all parts.

If the browser uses this modification time for an I-M-S request and if
one of the document's parts is fetched using a proxy mechanism the
original modification time of this part is no longer available. Thus,
the I-M-S time used in requesting this part may be later than the
modification time for this part and, refering to the example above, the
server should return 304, because this part has not changed.

I built up such an application which decorates arbitrary Web documents
with some schema links for guided tours, see at
	http://www.cs.vu.nl/~fjh/www5/
for more details. The overall modification time is computed using the
latest time of the original document and the guided tour configuration.

-- Franz

__
|_ _ _ __ __   |  |_| _     _|_    Fac. of Math. and Comp. Science
| | (_|| |/_ (_|. | |(_||_|(_|\    Vrije Universiteit Amsterdam
     __________________________)   http://www.cs.vu.nl/~fjh/
    (__________________            fjh@cs.vu.nl

Received on Wednesday, 14 February 1996 02:48:35 UTC