- 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>
> 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). However: 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. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 17 January 2003 07:36:20 UTC