double property bug?

[Ben Collins-Sussman <su...@collab.net>]

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.

Re: double property bug?

[Julian Reschke <ju...@gmx.de>]

Ben Collins-Sussman wrote:
> ...
> 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?
> ...

Right. There may be clients that actually won't touch the response body 
unless it's text/xml or application/xml.

 > ...

Best regards, Julian

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