RE: getcontentlength property and dynamically-generated content

Look at it from a client point of view. Client code would reach an
unacceptable level of complexity if every single value either could be there
or couldn't be there. We needed some sort of consistency so we choose an all
or nothing approach. IF you return GET then you have to return these
properties. That way the client only has two code paths, either the resource
doesn't support GET or it does have available the specified properties.

However server people didn't like this because sometimes the values are hard
to produce and lots of values may simply not be available.

So we had to strike a deal. Find a middle ground that both the server and
client folk could live with. The result is the current set of mandatory
properties.

So, that having been said, one needs to be both flexible and realistic. I
think the answer to your problem is caching. After having generated a GET
for a property I would cache the header values along with the e-tag that was
used in that GET and return that for HEAD and PROPFIND requests. If someone
follows the HEAD or PROPFIND with a GET and gets different values, so what?
That is the very nature of an asynchronous universe. Unless you are using
LOCKing, transactioning, or some other type of consistency guarantee the
only thing you can rely upon from request to request is that nothing will
remain the same. The only important caveat is to make sure that the headers
do match with the e-tag. Otherwise obviously bad things will result.

			Yaron

-----Original Message-----
From: Wesley Felter [mailto:wesley@scripting.com]
Sent: Tuesday, March 24, 1998 10:58 PM
To: w3c-dist-auth@w3.org
Subject: getcontentlength property and dynamically-generated content


I have an interesting situation and I'm hoping someone can offer a little
advice.

I'm writing a WEBDAV server that serves out of an object database (which is
just a hierarchial tree of objects). Objects can't be transmitted directly
from the database; they have to be serialized so that they can be
transferred over HTTP. When serving a GET request, the object is serialized
and then finding its Content-Length is easy.

However, when serving a HEAD or PROPFIND request, there is no way to find
the length without serializing the object (which can be a time-consuming
process if the object is large). It seems like a waste of effort to
serialize an object only to find its length.

As I understand the spec, my server should either send a Content-Length
header for GET and HEAD methods and the getcontentlength property for
PROPFINDs, or not at all. This is more strict than I would like.

Is there a way around this that I don't see? Should I just pay the penalty,
or should the spec be modified to support only sending the content length
when it is not wasteful to compute it?

Wesley Felter - wesley@scripting.com

Received on Wednesday, 25 March 1998 14:38:27 UTC