PROPFIND vs. Accept: vs. variants

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

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.