Re: More followups

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.

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


-----------------------------------------------------------------------
Chuck Shotton
cshotton@oac.hsc.uth.tmc.edu                           "I am NOT here."

Received on Monday, 5 December 1994 16:58:30 UTC