RE: Newbie questions

Apologies for long post. Corrections please if my interpretation is wrong as
its all IMHO...

> -----Original Message-----
> From: ajk@mds.rmit.edu.au [mailto:ajk@mds.rmit.edu.au]
> Sent: 19 June 2001 05:14
> To: w3c-dist-auth@w3.org
> Subject: Newbie questions
> 
> 
> Hi. I am new to this list so I appologise if these are 
> ignorant questions.
> I have been reading all the WebDAV (and DeltaV) documents I 
> can get my hands
> on, but have a few issues that I do not understand.
> 
> Q1: When are null resources created? You can "lock a null 
> resource in order
>     to lock the name". Is it that if you do a lock on a name 
> that does not
>     exist as a resource, a null resource is created? Are 
> there other ways
>     that null resources can be created? The text says you 
> lock a null resource
>     to create a lock-null resource. A lock-null resource has 
> properties and
>     appears under its parent container. A null resource does 
> not appear under
>     its parent. The definition of null resource is that it is 
> a resource
>     that responds to requests, which implies that it exists.

Null resources are not created, they don't exist in the first place as far
as the server is concerned. At least thats a convenient way of thinking
about them. In other words, any URL that is not bound to an existing
resource on the server is a null resource. The server detects that the
requested URL doesn't exist, and depending upon the request, will return 404
(e.g. for a GET) or whatever is appropriate.

One imperfect way of visualling this is if you tried to GET a file (on a
file system implementation), the server would respond with a 404 because it
cannot find the requested file (URL). Thus the requested URL is a null
resource. However, you could PUT the file there (assuming all
checks/permissions/etc passed).

When you lock a null resource (assuming parent existed), you get a lock null
resource (LNR), which has all the DAV properties and thus has state. LNRs
are purely to reserve the name (URL) and nothing else, in an attempt to
reduce conflict issues (as per the rest of locking). The general exected
behaviour is for a client to "create" an LNR (with a LOCK request) and then
do a PUT or MKCOL. Example, after a PUT the LNR is no longer locked (unless
its parent is infinitely depth locked) and is a "normal" resource, with
"entity data", in which you can GET it. Imagine multiple clients attempting
to perform PUTs on the same URL at the same time without LNRs.

Side note, LNRs can be returned to a null resource if server only implements
timed out locks, the timeout period expires and the server UNLOCKs the LNR -
see secs 9.8 and 7.4.

Maybe the spec could be better phrased as the use of the word "resource" in
so many different ways seems to fuel the confusion.

>     My guess is that any URI that is not bound to a resource 
> is implicitly
>     bound to a null resource which has no properties or any 
> other state.
>     When you lock a null resource, a lock-null resource is 
> created allowing
>     it to be placed under its parent container and have properties.
>     Is this correct?

Yep, though most DAV properties will be empty for the LNR.

> 
> Q4: PROPFIND in section 8.1 talks about responses and errors 
> and multistatus
>     XML elements. I have read the text several times but is confusing.
>     It says servers must support returning a multistatus 
> element. (It does not
>     say that it must *always* return one, just that it must 
> support it.) It
>     then says errors must be returned as 404 *if* a 
> multistatus element is
>     returned. etc. It was not clear when a multistatus element must be
>     returned - is it optional or mandatory? Related, how to 
> know when to
>     return multistatus elements in general? Examples of 
> packet communications
>     are given, but no formal request/response packet grammar is given.

Generally, 207 if a problem exists on a resource that was not the URL in the
request e.g. "recursive" operations such as DELETE, COPY etc. For PROPFIND
though, you might get a 207 because of multiple returned
problems/values/etc.

For example, you did a PROPFIND on a null resource, you shouldn't get a 207,
but a plain vanilla 404 as its the requested URL and its more meaningful.

If the PROPFIND request contained certain properties to be returned and as
an example, some of the properties didn't exist, server would return a 207
but contain 404 inside the XML for those properties that didn't exist. For
the properties that were found, their values would also be returned in the
207. This should indicate to the client that the requested resource existed,
but some of the properties don't.

> Q5: MKCOL behaviour with message bodies is not defined in the standard
>     (section 8.3.1) but may be "defined elsewhere". Is there any such
>     defintion around? Or is the body of MKCOL not important for
>     interoperability.

No definition that I know of.

In theory you could create an entire server with *one* MKCOL request e.g.
your request could create a collection which is a direct child off root, all
the descendants for the collection and all their properties. Hope your not
doing this down a 56k line :-)

> 
> Alan Kent
> 

Regards

Shaun Hall
Xerox Europe

Received on Wednesday, 20 June 2001 05:33:20 UTC