Re: PROPFIND vs. Accept: vs. variants
Werner Donné <werner.donne <at> pincette.biz>
2011-04-21 13:20:05 GMT
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.
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)?
> 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
> 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.
Handling your documents with care, wherever you are.