RE: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND 'allpr op' usage)

Wow, which message should I reply to ? :-).

This seemed to be the most appropriate.

Regards

Shaun Hall
Xerox Europe


> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: 27 November 2000 04:59
> To: w3c-dist-auth@w3.org
> Subject: 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 :-).

I originally suggested that we should keep the "depth:infinity" and
"allprop" separate and the EXAMPLE use of 507. I asked for people's
ideas/comments/etc. 507 as stated in my previous email, was just an example.
You guys are beating it to death which is a good thing for writing specs. 

> 
>    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?

When I meant 507, I did not mean for it to be in the XML part of the
response, but the actual HTTP response code e.g.:

	HTTP/1.1 507 Insufficent Storage
	Content-Type: xyz
	...

With such a code, no XML needs to be returned, no "partial response" is
given, "some properties are  omitted" etc. In other words, everything is
omitted, so the client doesn't have to parse a "largish" response etc (as
people have mentioned).

This way, the client doesn't have to be too clever in to figure out what
parts/properties/resources/etc the server omitted. It simply knows the whole
response for the request was too large. Being a little bit smart though, it
could then issue PROPFIND requests that would not generate such large
responses (i.e Depth:1).

This use of 507 may deviate though from RFC2518.

I do think that "pruning" the response (i.e. 507 XML in a 207 response) is a
bad idea and would be rather difficult for the client to handle.

[snipped]

> 
> 
>    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
> 

As I orginally asked, can people suggest ideas of how to handle PROPFIND
with a Depth:Infinity request, whilst trying to maintain backwards
compatibility with existing clients. In other words, 
if people are unhappy with my suggested use of 507, suggest something else.

Received on Monday, 27 November 2000 04:25:54 UTC