It seems my mail was not so clear. On Friday 29 January 2010, Plüm, Rüdiger, VF-Group wrote: > > The documentation > > http://httpd.apache.org/docs/trunk/mod/mod_dav.html#complex > > suggests using ForceType 'text/plain' to circumvent this. Apart > > from the fact that this is not enough and one may need > > 'SetHandler none' as well, I think this is a kludge. mod_dav > > should make sure that the GET request is handled by the default > > handler by setting r->handler in its fixup hook. If nobody > > disagrees, I will change this in trunk. > > Please do not. Some mod_dav providers need to implement their own > GET handler because the resource requested might not be a plain > file (e.g. it is stored in the database).
If this was not clear, I only want to change the behaviour for providers that do not implement their own GET handler, i.e. handle_get == 0. > Apart from Julians comments, SSI is a filter and can be applied to > these resources as well (no problem) and the same is true for PHP > if mod_php is build as a filter. Ok, filters are a different problem, then. But my argument still stands for mod_php as handler. > But usually: Use a different URL for WebDAV than for live access. That's what I want. But mod_dav makes it more difficult than necessary. Consider a configuration with mod_php like this: <FilesMatch \.php$> SetHandler application/x-httpd-php </Files> <Location /dav> Dav on </Location> Then I want mod_dav to serve the script source for /dav/test.php but instead I will get the script output from mod_php. To get the script source, I currently need: <Location /dav> Dav on SetHandler none </Location> In contrast, if I use a dav provider that handles GETs (like mod_dav_svn), I don't need the 'SetHandler none'. This is inconsistent. IMNSHO, if I set 'Dav on' for some Location, mod_dav has to ensure that it works, even for providers that don't handle GETs. Cheers, Stefan
