Re: Depth infinity PROPFIND

   From: "Hall, Shaun" <Shaun.Hall@gbr.xerox.com>

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

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.

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

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.

   This use of 507 may deviate though from RFC2518.

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

   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.

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

   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.

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

Cheers,
Geoff

Received on Monday, 27 November 2000 08:11:56 UTC