- 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
>> 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."
Maybe.
......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
Received on Monday, 5 December 1994 22:31:06 UTC