double property bug?

If you activate the feature:

    ModMimeUsePathInfo on

...within your <Location> block, then mod_mime automatically fills in
the r->content_type field in the request structure for an incoming
PUT. mod_dav_svn notices this during an autoversioning commit, and
responds by automatically setting an svn:mime-type property on the
file. Very nice. I'm about to document this in the book.

Unfortunately, this directive seems to have another weird side
effect, one which I just discovered.

Bug #1:

When doing a PROPFIND to fetch all properties of a file, the
'DAV:getcontenttype' property is being returned *twice*. The first
time it's our liveprops.c logic working: it looks at r->content_type
and uses that. Then later on, something else *outside* of
mod_dav_svn is attaching the property again! I've attached an
ethereal trace to demonstrate.

Bug #2: (?)

Beyond that, I think we're getting a little overzealous in our mime
stuff here, and wonder if we really know what we're doing --

For example, look at mod_dav_svn/repos.c:dav_svn_set_headers().
Notice that it, too, is looking at r->content_type and using that
value as the 'Content-type:' header in the response. For a PROPFIND
response, shouldn't the Content-type: header *always* be 'text/xml'?
The mime-type of the file itself is completely irrelevant in this
case, right?

Sure enough, it seems like 'text/xml' is there in the response
header... and then it shows up again as the 'DAV:getcontenttype'
propval in the body. Something is... wrong. I think we're severely
misinterpreting the meaning of r->content_type somehow.

    * is r->content_type describing the response type?

    * or is it describing the file contents?

    * or is it both? and how do we distinguish?

This is quite a muddle.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org