--On Friday, May 30, 2003 2:34 AM +0200 Andr� Malo <[EMAIL PROTECTED]> 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:
http://asg.web.cmu.edu/rfc/rfc2518.html#sec-5.4
And, of course, this issue is peripheral to Content-Type identification.
