Re: PROPFIND vs. Accept: vs. variants

On 20.04.2011 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)?
>
> 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".

I agree this is what *should* happen.

Probably what you see is an interaction between modules that nobody has 
considered before.

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

Accept means the same thing for all methods; it's the preference for the 
media type of the returned content. This is an aspect of HTTP, not WebDAV.

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

The WebDAV WG never got around to look into the interaction of content 
negotiation and authoring; I think the safest thing to do is not to try :-)

Best regards, Julian

Received on Thursday, 21 April 2011 13:20:50 UTC