- From: Henrik Frystyk Nielsen <frystyk@ptsun00.cern.ch>
- Date: Tue, 6 Dec 94 05:58:11 +0100
- 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 UTC