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

Re: More followups

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Mon, 05 Dec 1994 22:25:14 -0800
To: kball@novell.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9412052225.aa18763@paris.ics.uci.edu>
>> The length of the object-body that would have been returned had
>> the request been a GET.
> This is not very clear in the description of the Content-Length field
> that it describes the length of the object referenced by the URI,
> which may or may not be present in the message.  Maybe HEAD should
> return the description of the object as the object body of the message
> so such ambiguities and overloading dont occur.

I will clarify the description of HEAD.  The latter suggestion, though
appealing  from a design point of view, is outside the scope of HTTP/1.0.

> ...
> Doesnt the lack of a clear meaning of modification make this almost '
> useless, except maybe for a matched pair of client and server that
> have a common meaning.  It needs to reflect that either the content
> as returned is different then previous to the date.  I could also 
> reflect metainformation change, such as expiration updated.  But, I
> think that is a little too nebulous.
> Either way, some agreed meaning needs to be assigned to modified.

Well, there is an implied meaning as given by the name (i.e. when the
object was last modified).  What is not defined is how much (or how little)
modification needs to occur, and why.  All that matters is that the origin
server thinks that the object was last modified at the given time -- the
client is trusting that the server knows what it is talking about.

Perhaps we could define it in terms of how it is used, i.e.
"If you have a copy of this object which is older than the given LM date,
 that copy should now be considered stale."


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
Received on Monday, 5 December 1994 22:31:06 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:54 UTC