>> 2) Fails to include a Date: header on responses. This header is necessary
>> for cache management.
> Can you explain this? If the Date: is just the current time doesn't the
> client/proxy server know it as well as the server.
Because it provides the time that the server "thinks" is the right time --
that has an effect on the Last-modified date and also lends a clue as to
which date format/time zone the server is using. Both of these are unnecessary
if the client is directly connected to the server and the connection is
working properly, but that is not always the case.
For example, think of what happens when we have a two-tiered cache
hierarchy. The cache closest to the origin server will know the date from
when it requested that document from its origin. However, the cache
below it only knows when it connected to the cache above (getting the
cached copy there) and whatever is enclosed in the message. If the message
contains a Date header, it can tell from that header how "old" is the message.
This is important because there are many applications which require a
window of "timeliness," and this is the only way to guarantee that
timeliness without doing a "Pragma: no-cache" on all requests.
The other reason for having it is to maintain a proper rfc822/MIME message
which can be gatewayed through to mail, netnews, etc. without changing
the message. Since that is one of the main reasons we are passing around
text headers, it is a bit silly to leave them off.
>> 4) Does not support the If-Modified-Since header (conditional GET protocol)
>> that allows for efficient cache updates.
> This may be a "good thing", but it is not in the HTTP/1.0 spec and hence
> a server claiming to be HTTP/1.0 shouldn't be called broken for that
Yes it is -- it's in the HTTP2.html spec, which is the only one that
currently specifies the HTTP/1.0 protocol. I guess it's time to correct
....Roy Fielding ICS Grad Student, University of California, Irvine USA
<A HREF="http://www.ics.uci.edu/dir/grad/Software/fielding">About Roy</A>