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

From: "Hall, Shaun" <[email-masked]>
Date: Mon, 27 Nov 2000 09:19:22 -0000

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:[email-masked]]
> Sent: 27 November 2000 04:59
> To: [email-masked]
> 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 <[email-masked]>
> 
>    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.

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 27 Nov 2000 08:11:09 -0500 (EST)

From: "Hall, Shaun" <[email-masked]>

Yes, a top level 507 response is appropriate, and tells the server that
the request needs to be re-issued with a smaller Depth value.  But a nested
507 response inside of a 207 is also appropriate when the server is
willing to process a limited amount of what the client asked for.

The use of nested 507's inside of a 207 This saves the client the
guesswork of what is a "reasonable" Depth value.  Depth:1 can always
be used, but it might generate significantly fewer requests if you
let the server pick the depth.

Any use of 507 in this way deviates from the spec (it is not defined as
being a response from a PROPFIND), but it is a "benign" deviation, since
although it may surprise existing clients, it doesn't "change" the
meaning of a 507 from a PROPFIND (since there was no prior meaning).

Because ... ?  It was ready to parse the XML, and needed to handle errors
in the nested results, so the only additional thing it needs to do is
to issue another PROPFIND whenever it encounters a 507 (assuming it wants
to do so ... it might not if it wasn't expecting a deep/wide tree).

The only argument against 507 has been "it's hard for clients" ...
but I don't yet see how it is hard.

Cheers,
Geoff