Re: If-Modified-Since and 304

"Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 11 Mar 1994 14:36:22 --100
Message-id: <9403110531.aa06572@paris.ics.uci.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: fielding@simplon.ICS.UCI.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: If-Modified-Since and 304
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2161
Ari's last message was right on the mark regarding the interpretation
and format of the If-Modified-Since: header.  The date must be in HTTP
format (whatever that is) and is always GMT.  Also, the Expires header
is the appropriate place to indicate "don't cache."

John Ellson brought up an interesting point in indicating that the cache
manager could just save the cached document's prior Last-modified "tag"
and pass that back in the If-Modified-Since header.  However, I think that
is an implementation issue for cache managers and should not be considered
part of HTTP.  All that should be required of future servers is that they
be able to parse an HTTP date format and behave according to the spec.

As to the HTTP date format itself, Rik Harris has brought up a topic that
I have talked about before in that the format used by current servers

> Date: Thursday, 10-Mar-94 19:20:00 GMT
> Last-modified: Thursday, 10-Feb-94 22:23:32 GMT

is based on an out-of-date standard (rfc850).  The format should be
changed to this:

  Date: Thu, 10 Mar 1994 19:20:00 GMT
  Last-modified: Thu, 10 Feb 1994 22:23:32 GMT

because it is of fixed length, completely unambiguous for both machines and
humans, and is used by most Internet-based mail and NNTP servers
(with the exception that HTTP only uses GMT for timezone).  However, such
a change will have to be decided upon by the server authors and then placed
in the HTTP2 spec before servers and clients can rely upon it.  For now
(and probably for the next year or so), clients like the one I'm building
will have to be able to parse and understand both formats.

BTW, my server <http://www.ics.uci.edu/> has been using the latter format
since December with no problems -- it is just a one line change in the
NCSA httpd code.  My wwwstat program (written in Perl) also generates that
format and anyone is welcome to use the subroutine in it called wtime.
I'll be working on Perl code to parse both formats next week.


...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>