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

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

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