W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2011

PROPFIND vs. Accept: vs. variants

From: Wim Lewis <wiml@omnigroup.com>
Date: Wed, 20 Apr 2011 14:07:01 -0700
Message-Id: <B3D0144C-B59D-4F32-91C8-7B94529AE9B7@omnigroup.com>
To: w3c-dist-auth@w3.org
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)?

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.

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

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

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.

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.

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.
Received on Thursday, 21 April 2011 12:49:29 UTC

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