Re: If-Modified-Since enhancement

Roy T. Fielding (fielding@simplon.ICS.UCI.EDU)
Tue, 22 Mar 1994 07:43:18 --100


Ari said:

> Since nobody objected, and some gave me feedback saying it was
> a good idea,

That's what I get for sleeping-in this morning...

> the HTTP spec now says:
>
>
> NOT MODIFIED 304
>
> If the client has done a conditional GET and access is allowed, but
> the document has not been modified since the date and time specified
> in If-Modified-Since field, server responds with 304 status code, and
> does not send the document back to the client.
>
>NEW: Response headers are as if the client had originally sent a HEAD request.
>NEW: This way the server can upload a new expiry date and other necessary
>NEW: metainformation to the requesting client (often a caching proxy).
>
> This is to allow fast update of caches.

Sorry for the late response (it's Monday here in California), but I don't
support this change at all. The whole purpose of the If-Modified-Since
proposal is to eventually save network bandwidth. That purpose is partially
defeated if we send ALL the document headers even though both the server
and the cache manager know that the document has not been modified.
At least 99.999999999% of the time they will be identical to those already
stored by the cache manager.

The only headers which should be sent are

Date:
Server:
Expires:

all of the other headers (especially the MIME ones) serve no purpose
in a NOT MODIFIED 304 response and thus IMHO should never be sent.

Have I overlooked something?

...Roy Fielding ICS Grad Student, University of California, Irvine USA
(fielding@ics.uci.edu)
<A HREF="http://www.ics.uci.edu/dir/grad/Software/fielding">About Roy</A>