W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: PROPFIND returning *more* than expected, and other questions

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 17 Jan 2003 13:35:46 +0100
To: "Joe Orton" <joe@manyfish.co.uk>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEJEGDAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton
> Sent: Friday, January 17, 2003 9:32 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: PROPFIND returning *more* than expected, and other
> questions
> On Thu, Jan 16, 2003 at 04:42:13PM -0800, Chris Knight wrote:
> >
> > Julian Reschke wrote:
> > >>behaviors for properties. Say, for example, you requested <foo:author>
> > >>and the resource had <foo:author>, <foo:author_name>, and
> <foo:authors>
> > >>the server's response would contain all of these properties.
> > >
> > >
> > >If you do this upon PROPFIND/prop, that's illegal.
> >
> > I thought this too but I didn't find anything in the RFC that
> would make
> > such behavior illegal. I don't think it's worthy of inclusion
> in the RFC
> > but a clarification of this would be worthwhile.  (Clarification being
> > must the server only respond with the values requested?)
> I asked this very same question a few years ago - Yaron said it's
> perfectly legal for the server to return extra properties since the
> client must ignore unknown/unexpected elements.
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0196.html

I have to say that I disagree. It's correct that unknown protocol elements
should be ignored, but the contents of DAV:prop is one of the few places
where there *cannot* be unknown elements. Each child element of DAV:prop
identifies a property, so this has nothing to do with the extensibility
rules defined in the RFC2518 appendices.

Currently section 8.1 says:

"A client may submit a propfind XML element in the body of the request
method describing what information is being requested. It is possible to
request particular property values, all property values, or a list of the
names of the resource's properties. A client may choose not to submit a
request body. An empty PROPFIND request body MUST be treated as a request
for the names and values of all properties.

All servers MUST support returning a response of content type text/xml or
application/xml that contains a multistatus XML element that describes the
results of the attempts to retrieve the various properties."

I agree that this is a bit inprecise and should be clarified (right now,
most of the wording is in the examples which isn't a good thing).


1) If a server returns more properties than requested, I'd really like to
understand why. In the example you posted back then, it certainly seems to
be a bug in the server. Does anybody really have a use case?

2) I'd claim that a conforming client may reject the response because it
does contain properties that weren't requested. So for the sake of
interoperability, servers MUST NOT return properties that weren't requested.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 17 January 2003 07:36:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC