RE: Label header vs PROPFIND depth 1

Juliam wrote:

> > Right, so imagine what kind of answer you would get back in the
> > multistatus -- some would be from the unversioned resource propfinds and
> > some from version propfinds, and you wouldn't know which were versioned
> > (without explictly looking for a live property to distinguishe
> > them), _and_
>
> Yes -- I think this is what RFC3253 says.
>
> > it would contravene the 2518 depth result requirement I
> mentioned earlier.
>
> I don't think so.

From your example below I see that you envisage the hrefs being those of the
version-controlled resource (even though the properties come from the
labelled version).

This is too confusing.  Al the existing code that people write to associate
the href with the properties would have to be re-written as the reported
properties are from a different resource to the href.

> > a version-controlled resource for which the label doesn't exist?
> > >
> > > See section 8.6, the DAV:must-select-version-in-history precondition.
> > > It is an error if you request a label that does not exist on a
> > given VCR.
>
> So assume we have /a (collection, not-versioned), /a/b
> (not-versioned), /a/c
> (versioned, having a version labeled "x") and /a/d (versioned,
> without that
> label).
>
> I think we all agree that
>
> GET /a/c
> Label: x
>
> Should return the content of the version selected by the label x
> (including
> a vary header and probably a content-location header).

Agreed -- I think we specify a Location: header, but whatever (i.e. resource
location, not content location).

> GET /a/d
> Label: x
>
> will return 403 or 409 with an error element (precondition
> DAV:must-select-version-in-history failed).

Agreed.

> GET /a/b
> Label: x
>
> will just return b's content, and the vary header when present will NOT
> include "Label".

Can I hedge on the vary: header in the response?  Given that the GET cache
may be invalidated by the resource /a/b coming under version control, and
acquiring a label, I may be inclined to believe that we should return a vary
header for every label: request for a version-controlled or versionable
resource.

> Similarily, similar results will be returned for a PROPFIND/depth
> 0 on these
> resources. Note that the response element will be "/a/c" in the
> first case, even if the properties of a version with a different
> URI were reported.

No.  I think the href must be for the version resource selected by the
label, not the version-control resource at the request-URI.

> Finally, we have PROPFIND/depth 1 on /a:
>
> - as /a isn't version-controlled, the label header is ignored for *this*
> resource
>
> - Geoff and I claim that it *should* apply to the members then,
> so we'd get:

...and I say it shouldn't apply to members, otherwise the result will
contain properties from resources that are not in the same collection
membership hierarchy, and thereby contravene 2518 (as well as complicate the
result enourmously).

Regards,
Tim

Received on Tuesday, 23 April 2002 04:57:40 UTC