httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Knight <>
Subject Re: automatic type identification (by extension) in virtual DAV repositories
Date Fri, 30 May 2003 16:23:21 GMT
Justin Erenkrantz wrote:

> --On Friday, May 30, 2003 2:34 AM +0200 André Malo <> wrote:
>> ModMimeUsePathInfo was created for this purpose IIRC.
> Indeed.  The only caveat is that ModMimeUsePathInfo shouldn't 
> necessarily be enabled on resources that you edit.  The problem comes 
> into play when filters are applied and the transmitted representation 
> differs from the on-disk (in-storage) resource.  (This is actually a 
> major collision with REST that WebDAV never quite solved cleanly - it 
> just assumes that the resource == representation.)

Note that Content-Type identification would only come into play when the 
Content-Type was not explicitly identified by the original PUT (as 
happens with the Win32's Web Folders client and the Cadaver client and 
surely many others.) Would it be better, instead, to not send a 
Content-Type header at all? (It appears that find_ct defaults to 
text/plain if it's unable to determine type by extension, should it 
instead do nothing?)

> The best example is with mod_include'd files.  With ModMimeUsePathInfo 
> On, there is no way to disable the output filters when communicating 
> with a DAV client.  Therefore, the solution is to mount the repository 
> twice - once as read-only with ModMimeUsePathInfo On and another one 
> with it Off so that the DAV clients can modify without having the 
> filters executed and get the 'raw' representation.
> Hope that makes sense.  If not, I can try to clarify.  -- justin

Already addressed by the WebDAV spec, see:

And, of course, this issue is peripheral to Content-Type identification.

View raw message