PROPFIND vs. Accept: vs. variants

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

PROPFIND vs. Accept: vs. variants

Wim Lewis-3
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.





Reply | Threaded
Open this post in threaded view
|

Re: PROPFIND vs. Accept: vs. variants

Werner Donné-2
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.


Reply | Threaded
Open this post in threaded view
|

Re: PROPFIND vs. Accept: vs. variants

Julian Reschke
In reply to this post by Wim Lewis-3
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

Reply | Threaded
Open this post in threaded view
|

Re: PROPFIND vs. Accept: vs. variants

Geoffrey M Clemm
In reply to this post by Wim Lewis-3

WRT the "related question", the first interpretation is correct.
 
A server is allowed to associate multiple URLs with the same resource, and in particular, may chose to do so to have a different "default representation" that is provided when the client requests a resource with no Accept header.

Cheers,
Geoff

[hidden email] wrote on 04/20/2011 05:07:01 PM:

> From: Wim Lewis <[hidden email]>

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