Re: PROPFIND vs. Accept: vs. variants

Hi Wim,

My understanding is that Accept is the same for a GET or a PROPFIND. It =
is just an indication of the client about the acceptable forms for the =
representation of a resource. The format for the response body of a =
PROPFIND is application/xml. It the client requests this in another =
format then either the server responds with a 406 or it transforms the =
data to the desired format if it supports it. I think this is allowed =
because RFC4918 says:

"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."

This doesn't preclude other representations of the data. A server could, =
for example, support also a JSON representation or an OPDS =
representation, etc.

Using Accept for the selection of a variant is possible for a GET, but =
then I think foo.txt and foo.png are the representations of two entities =
of the resource foo. As a consequence, the properties are always the =
same, which means Accept can't be used to select a variant for a =
PROPFIND. Properties are related to resources and are not affected by =
the Accept header.

Regarding the related question, I think that if "foo" corresponds to =
different resources depending on content negotiation, then this always =
implies a redirect to one of those resources.

Best regards,

Werner.

On 20 Apr 2011, at 23:07, Wim Lewis wrote:

> I've encountered some behavior that surprised me from Apache's mod_dav =
and I'm trying to figure out what the correct behavior is. Specifically, =
what is the interpretation of the Accept: header sent with a PROPFIND =
(or other DAV request other than GET)?
>=20
> I have a server with mod_dav and MultiViews enabled, and files foo.txt =
and foo.png. As a result of this, Apache presents a resource at 'foo', =
whose content and content-type vary depending on the Accept: header sent =
in the GET request. This is as expected and as desired.
>=20
> If I do a PROPFIND on that resource, I get information about either =
the txt or the png variant, depending on the Accept header sent in the =
PROPFIND request. If I supply 'Accept: application/xml', then the =
PROPFIND fails entirely with HTTP status 406. So clearly Apache is using =
the Accept: header to select the variant on which to run the PROPFIND. =
This is unexpected (to me), but makes a certain amount of sense. (The =
<href> in the PROPFIND result always returns the url with the =
appropriate extension --- the canonical URL for the file that supplied =
that variant.)
>=20
> I had thought, however, that PROPFIND requests should include 'Accept: =
application/xml', because that is the content-type of the result body I =
want from the PROPFIND. RFC2616 describes Accept (and Accept-Charset =
etc) as being "used to specify certain media types which are acceptable =
for the response".=20
>=20
> So, my question is: what is the meaning of Accept: in a PROPFIND =
request? RFC2616 implies that a PROPFIND's Accept: header, if present, =
should be application/xml, and in Apache's case, this works for =
non-varying resources, even ones that aren't XML.  On the other hand, =
Apache is using it to select the variant to which to apply the =
operation, regardless of the media type which will appear in the =
response. Apache's behavior seems more *useful*, since it allows me to =
discover canonical URLs for a varying resource.
>=20
>=20
>=20
> A related question, in the context of rfc4918 section 5, is how =
variant resources are modeled in terms of segment-to-resource mapping. =
My initial understanding was that the 'foo' path segment mapped to a =
single resource, whose content and properties varied based on content =
negotiation. The fact that the resource didn't correspond to a =
particular disk file was an implementation detail and unimportant.
>=20
> The other interpretation is that the 'foo' segment maps to different =
resources depending on content negotiation. This seems to be the =
approach that Apache is taking, since in each case the PROPFIND response =
indicates the more-canonical URL for the resource whose properties are =
returned. rfc4918 states "it is illegal to have the same path segment =
mapped to more than one resource", but it is only mapped to one resource =
during any given request, so perhaps that is OK.
>=20
>=20
>=20
>=20
>=20

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.