Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND 'allprop' usage)

Note that the 507 proposal is not for dealing with allprop,
but rather with dealing with depth infinity, so I've modified
the subject line (Kevin valiantly tried to separate the issues,
but they seem to keep getting mashed back together :-).

   From: Greg Stein <gstein@lyra.org>

   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?

If it gets a 507 as the top level status, it knows it has to retry
the request with a smaller depth.  If it gets a 207 as the top level
status, and a 507 as the status of some member, it has to retry the 
request on that member directly.

   How does
   it know *what* was left out,

It knows by what results are 507's and what are 200's.  Note: the
proposal is not that you use a 507 to omit some of the properties in a
response element, but rather to omit *all* of the requested properties
in the response element.

   and *how* to get those results?

See above.

   Did the server do a depth-first or a breadth-first response of
   properties?

I assume you mean, a depth-first or breadth-first search of
the members?  If so, you would be able to tell by what response
elements are 200's and what are 507's.

   Which collections did it recurse into and which did it
   not? Did it stop *partway* through a collection? How can a client
   tell?

We would need to define server behavior here.  For example: "you have
to return the properties of a collection if you are going to return
properties of any of its members, and you return 507 if you are not
going to return properties of the collection or any of its members,
due to space limitations".

   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.

If we define it properly, it only has to retry the 507's.

   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.

Just prune out all the responses whose URL match certain prefixes,
and return a 507 for the collections that you pruned out.

   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").

Yes.  (What don't you like about this alternative?)

   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.

I'm not quite sure what you are referring to here.  The 507's are for
pruning responses when the depth is too great, and is independent of
whether it is a propname or prop style PROPFIND.

   Personally, I say punt the 507 and specifically allow 403 responses.

The 403 would definitely leave the client in the dark ... it wouldn't
know whether or not to retry the PROPFIND with a different depth.
Whereas the 507 tells the client very clearly that it is the depth
value that is too great, while still giving it some of what it asked
for.

Cheers,
Geoff

Received on Sunday, 26 November 2000 23:59:36 UTC