W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: More followups

From: Henrik Frystyk Nielsen <frystyk@ptsun00.cern.ch>
Date: Tue, 6 Dec 94 05:58:11 +0100
Message-Id: <9412060458.AA02073@ptsun00.cern.ch>
To: Chuck Shotton <cshotton@oac.hsc.uth.tmc.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, kball@novell.com
Chuck Shotton writes:
 > At 6:06 PM 12/5/94, Keith Ball wrote:
 > >> From "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
 > >>
 > >> > 1. In a HEAD response, what should Content-Length be set to?  The
 > >> >    length of the (non-existent) object body, or 0?
 > >>
 > >> The length of the object-body that would have been returned had
 > >> the request been a GET.
 > 
 > Not to be a party pooper, but what about URIs that point to things like
 > CGIs which generate content on the fly? Would it be appropriate in this
 > situation to not return a content-length header? Zero would be as wrong as
 > any other number in this case.

As dynamic objects don't have a default Content-Length the right thing
to do would be not to send the header field at all. This is one of the
the reasons why the field can not be mandatory.

 > >> > 2. Is there a view on how locally-time-stamped data should have their
 > >> >    Last-Modified GMT computed?  It's impractical to recreate the
 > >> >    true original GMT time-stamp (as the timezone and daylight savings
 > >> >    regime of the place of last modification is usually unknown).  Using
 > >> >    the current GMT offset will result in the timestamp of some data
 > >> >    jumping forwards or backwards an hour, twice a year, which could
 > >> >    affect caching.
 > >>
 > >> There are many views as to how this should be done, but none of them
 > >> are within the realm of the HTTP protocol.  All that matters is that
 > >> the date used within the protocol is GMT (UT).  How the date is obtained
 > >> (and, in fact, what it means to be "modified") is entirely up to the
 > >> application sending the object.
 > 
 > In truth, it's possible that it doesn't even matter if the conversion to
 > UTC is done or not, as long as the server is consistent. Simply appending a
 > GMT to the local time can work, since the clients are asking for changes
 > from a previously returned time. As long as the time is consistent (and
 > different), IMS will work. This breaks things like clients that
 > automatically expire, but is this a valid use of IMS anyway?
 
Ohh - this would screw up a lot of cache managers which use the LM
(which is the previously returned value) if the expired header is not
present. They don't like to get a future last modified date!
I would not recommend this at all!

-- cheers --

Henrik
Received on Monday, 5 December 1994 20:59:46 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:09 EDT