RE: [RFC2518 Issue] PROPFIND 'allprop' usage

I agree with the desire for the client to find out *what's* missing, and the
207 multistatus allows a server to fill in a "507" response for each
property that it chooses to omit due to processing or space limitations.
E.g. a depth-0 'allprop' response could still legitimately omit the value of
the ACL property but mark its presence with the 507 status code.

However, I'm not sure it's so easy for a server to indicate that it has
omitted a whole hierarchy in a 207 multistatus response.  What if the client
asks for depth-infinity 'allprop' on a directory with sub-directories?  I
guess the server could:
 - for every item in the directory that is not a sub-directory, respond
normally with property values or property status codes
 - for sub-directories that it wishes not to recurse into, include this kind
of XML

	<DAV:response>
		<DAV:href>/subdir</DAV:href>
		<DAV:status>HTTP/1.1 507 Insufficient Storage</DAV:status>
	</DAV:response>

This appears legal under RFC 2518's definition of the elements that can/must
go in the response element.

   <!ELEMENT response (href, ((href*, status)|(propstat+)),
   responsedescription?) >

I don't see any way for the server to return the properties for 'subdir'
while simultaneously indicating to the client that it did not recurse into
'subdir'.  Thus in order to limit its answer, the server would omit the
property set for 'subdir' as well.  Not the best of solutions; anybody have
brighter ideas?

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein
> Sent: Sunday, November 26, 2000 6:10 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage
>
>
> On Sun, Nov 26, 2000 at 08:34:45PM -0500, Geoffrey M. Clemm wrote:
> >
> > I heartily support the removal of allprop from the protocol.
> >
> > If client writers start now to replace their use of allprop-PROPFIND
> > with a propname-PROPFIND/PROPFIND pair, they have plenty of time
> > to be in compliance with a revision of 2518 that does not support
> > allprop.
>
> I vehemently agree. :-)
>
>
> I also support limitations on Depth:infinity requests (as if you couldn't
> guess :-).
>
> [ mod_dav (by default) just tosses them, responding with 403 (Forbidden);
>   since that is a legal return for a PROPFIND, it seemed to make
> sense in my
>   situation (and clients would have to deal with it anyways). ]
>
> Returning 507 would be a bit more difficult implementation-wise.
> However, I
> think we really shouldn't allow that mechanism. What is a client
> to do when
> it gets a 507? How does it know *what* was left out, and *how* to
> get those
> results? Did the server do a depth-first or a breadth-first response of
> properties? Which collections did it recurse into and which did
> it not? Did
> it stop *partway* through a collection? How can a client tell?
>
> With all of those problems, a client has to be *extremely* smart
> to recover.
> It would have to sort through the returned hrefs, analyze the
> structure, and
> try to determine where the server left off.
>
> Pathological case: let's say that I implemented the server with a database
> mapping URLs to property sets. I have a spiffy query that returns all rows
> that start with a particular URL base. For performance purposes,
> I *do* not
> sort the response, and the database does not guarantee one. Oh oh... what
> now? I've got responses in a scatter plot all over the URL namespace.
>
> One alternative would be for the server to "prune" responses and
> mark these
> prunings in the response. The client could then know exactly what
> is missing
> ("<this> resource" or "<that> collection"). This mechanism would also be
> nice for a "propname" or a "prop" style of PROPFIND with Depth:infinity. I
> could easily see a server wanting to prune those, too.
>
> Personally, I say put the 507 and specifically allow 403 responses.
>
> [ I wouldn't mind if Depth:infinity was tossed altogether, but that is too
>   extreme, and that depth is *very* handy for debugging :-) ]
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>

Received on Sunday, 26 November 2000 22:51:34 UTC