RE: empty resources

At 06:33 PM 3/10/98 PST, Jim Whitehead wrote:
>> ...can I do a PROPPATCH on a URI for an empty resource?...

>We don't explicitly permit this operation in the -07 spec. because if you 
>create properties on a null resource, that resource becomes non-null, and 
>then has a body as well.  This creates an awkward situation where there is 
>a non-null resource without a content type.  To set properties on a null 
>resource, first do a PUT with a Content-Type header and a zero length body, 
>creating a resource with a known content type, and an empty body. Then, 
>perform a PROPPATCH on this empty resource.

I would like you to clarify this, so there is no doubt.  It should be
either explicitly forbidden, explicitly allowed ('may'), or explicitly
required.  At the very least, it should explicitly be left undefined, which
would serve as a warning to the cautious not to rely upon it.

I had been assuming for weeks that it *was* supported, because LOCK seems
to rely on it. My server supports it, and I've written client code that
relies on it.  Naturally I'll change my code to comply with the standard,
but I want the standard to be clear on the point.

So.  Are you saying that a PROPPATCH on a null resource MUST fail (with a
404)?

I would be the first to admint that making such support mandatory would be
a burden on implementors, at least those implementing on a file system.  It
was a pain for me, that's for sure.

Another clarifiction question:

6.3 says that a write lock on a null resource makes the resource act "in
all ways as a null resource, except that it MUST respond to a PROPFIND
request".  This raises two questions
 1.  What about the collection that contains it?  In particular does the
null resource appear in its list of members if one does a PROPFIND of
non-zero Depth?
 2.  What about PROPPATCH?  Does that work?

Oh, and I know it's picky, but shouldn't UNLOCK also be included in the
list of requests it must support?  

yours in seeking clarity

Jim

Received on Thursday, 12 March 1998 14:36:36 UTC