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

> 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