If a collection in a WebDAV-enabled area contains an index.html (or whatever filename is specified in DirectoryIndex) then it becomes impossible to use WebDAV methods on that collection: you cannot PROPFIND it, MOVE it, DELETE it, etc. All of these result in a 405 Method Not Allowed error. e.g., this series of operations, starting from an empty directory "/wiml": MKCOL /wiml/bugzillaPF/ --> 201 Created MKCOL /wiml/bugzillaPF/testcollxn --> 201 Created PROPFIND /wiml/bugzillaPF/ --> 207 Multi-Status PROPFIND /wiml/bugzillaPF/testcollxn/ --> 207 Multi-Status PUT /wiml/bugzillaPF/testcollxn/index.html --> 201 Created PROPFIND /wiml/bugzillaPF/ --> 207 Multi-Status PROPFIND /wiml/bugzillaPF/testcollxn/ --> 405 Method Not Allowed DELETE /wiml/bugzillaPF/testcollxn/ --> 405 Method Not Allowed Notice that before index.html is written, it is possible to PROPFIND the testcollxn collection. Afterwards, that method results in an error. It's still possible to see the testcollxn by calling PROPFIND on its parent with Depth:1, though (and its resourcetype is <collection>, so one would expect to be able to issue other DAV requests against it). DELETE and MOVE suffer similarly. Setting DirectoryIndex to 'disabled' fixes the problem (at the cost of disabling directory indexes...). This shouldn't be necessary, as RFC4918 explicitly calls out the possibility that a collection resource can also have a GETtable entity in addition to its collection-nature. Also oddly, the error text returned for a PROPFIND on /wiml/bugzillaPF/testcollxn/ is "The requested method GET is not allowed for the URL /wiml/bugzillaPF/testcollxn/index.html." --- note that neither the method nor the URL mentioned in the response correspond to those in the request --- which is doubly unexpected because GET *is* allowed (and works fine) on that URL. In fact, PROPFIND is also allowed on that URL. Just not on "testcollxn". The (mis)behavior is the same in httpd-2.4.4 and in 2.5.0-dev r1477687.
Fixed on trunk with r1561447.
I haven't proposed this patch for backport to 2.4.x yet because it doesn't deal with OPTIONS, and I don't yet have a solid proposal on that front. With 2.2.x and 2.4.x, OPTIONS on a directory (e.g., "OPTIONS / HTTP/1.0") would return variable Content-Type response header values, depending on whether a DirectoryIndex file was found by mod_dir. If found, the Content-Type was derived from the index file (e.g., text/plain or text/html). If not found, the supposedly internal MIME type httpd/unix-directory is returned (which is arguably an error, but a long-standing one). With this patch, httpd/unix-directory is always returned, even if a DirectoryIndex file exists. Personally, I think it would be preferable to either: a) Restore (in trunk) the long-standing but arguably incorrect behaviour in which httpd/unix-directory is only returned if no DirectoryIndex file is found, or b) Adjust mod_dir and/or other modules so that httpd/unix-directory is never returned (e.g., by not returning Content-Type at all when r->content_type is set to an internal MIME type). While (a) might be the "safer" option, it may also may be harder or uglier to implement, with additional workarounds for the fact that r233369 (PR 25435) ended up breaking a number of other standard behaviours (e.g., PR 53794). This is because that change (r233369) lets mod_dir proceed with its internal redirect to the DirectoryIndex file, as if it was always the canonical handler for the request, but retains some aspects of the original request, like the method and original handler setting. When the original handler was never set, or can work equally well with a directory as with an index file, there's no problem; indeed, it can be a feature. (This is what the reporter of PR 25435 wanted for their mod_perl setup.) But when the original handler is set and the system is not expecting to have the request rewritten to point to an index file (e.g., mod_dav, mod_rewrite), things go awry.
Workaround: Add to webdav location <Limit PROPFIND> DirectoryIndex never-encounterable-file-name.html </Limit>
(In reply to Sergey Dorofeev from comment #3) > Workaround: > > Add to webdav location > > <Limit PROPFIND> > DirectoryIndex never-encounterable-file-name.html > </Limit> FWIW, this workaround doesn't work for me (2.4.7-1ubuntu4.1 trusty). WebDAV works, yes, but it breaks the directory indexing for normal requests -- GETs and all. Maybe that's a /different/ bug, I dunno... :-( Also, RE: Backporting to 2.4... Even though the patch above doesn't solve the WHOLE problem (i.e., the OPTIONS method) if fixing only PROPFIND is enough to "un-break" WebDAV, it's worth it, IMHO. Like we say at $WORK: "If it's stupid, BUT IT WORKS, it isn't stupid." (Also: "Just because you can't do /everything/ doesn't mean you shouldn't do *ANYTHING*") My two cents (and upvote)...
(In reply to Dabe Murphy from comment #4) > FWIW, this workaround doesn't work for me (2.4.7-1ubuntu4.1 trusty). > > WebDAV works, yes, but it breaks the directory indexing for normal requests > -- GETs and all. Maybe that's a /different/ bug, I dunno... :-( Same problem exists for me on Scientific Linux 7.0, httpd-2.4.6-18.sl7.x86_64 > > Also, RE: Backporting to 2.4... Even though the patch above doesn't solve > the WHOLE problem (i.e., the OPTIONS method) if fixing only PROPFIND is > enough to "un-break" WebDAV, it's worth it, IMHO. I agree. In this case I think backporting the fix would be worthwhile to most users even if the whole OPTIONS issue is not addressed at this time.
Hi there, I can confirm this issue on Apache 2.4.6. Server version: Apache/2.4.6 (CentOS) Server built: Jan 12 2015 13:22:31 Server's Module Magic Number: 20120211:23 Server loaded: APR 1.4.8, APR-UTIL 1.5.2 Compiled using: APR 1.4.8, APR-UTIL 1.5.2 Architecture: 64-bit CentOS Linux release 7.0.1406 (Core) The workaround that Wim Lewis talks about solves the issue, as this disables mod_dir for the defined context. On my case I've just applied to my WebDAV directories.
So it's been there for 4 years, not fixed for 2.4. Why? Nobody is interested in DAV working with DirectoryIndex? I really need both functionality.
Hi there, We had the same problem while doing an exercise. This is how we did it: Alias /webdav /exampleFolder DavLockDB /www/exampleFolder/webDavDB <Location /webdav> DAV On Options +Indexes AuthType Digest AuthName "webdav" AuthDigestProvider file AuthUserFile /www/exampleFolder/auth/.password Require valid-user DirectoryIndex disabled </location>
This bug goes beyond WEBDAV. In my case, I have a tomcat application behind Apache. If I configure DirectoryIndex index.html, and then tell Apache to pass all requests to tomcat ajp worker by way of: <Location "/"> SetHandler jakarta-servlet SetEnv JK_WORKER_NAME ajp13 </Location> Then if in my root directory, there exists a file called index.html, an incoming request for / will get translated to /index.html and then passed to tomcat where as in Apache 2.2, with the same DirectoryIndex index.html directive, the request for / was untouched as passed to tomcat as '/' and not '/index.html'. If I were to delete the index.html file, then '/' is passed.
Is there any news?
(In reply to Chris Darroch from comment #2) > I haven't proposed this patch for backport to 2.4.x yet because it doesn't > deal with OPTIONS, and I don't yet have a solid proposal on that front. Darn, I missed the ten-year anniversary of the OP's initial bug report! (FTR, I just ran into the same problem Yet Again today...) Maybe we can get this trivial, three-line, "Good Enough" patch backported to 2.4.x before it, too, has been around for a full decade? To repeat: "Just because you can't do /everything/ doesn't mean you shouldn't do *ANYTHING*" Thanks!! :-D
(In reply to Dabe Murphy from comment #11) > (In reply to Chris Darroch from comment #2) > > I haven't proposed this patch for backport to 2.4.x yet because it doesn't > > deal with OPTIONS, and I don't yet have a solid proposal on that front. > > Darn, I missed the ten-year anniversary of the OP's initial bug report! > > (FTR, I just ran into the same problem Yet Again today...) > > Maybe we can get this trivial, three-line, "Good Enough" patch backported to > 2.4.x before it, too, has been around for a full decade? > > To repeat: "Just because you can't do /everything/ doesn't mean you > shouldn't do *ANYTHING*" > > Thanks!! :-D Does https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directorycheckhandler help here? The short patch is not conditional at all and has no specific connection to the interaction with mod_dav so it may be good enough but probably the same could have beeen said of whatever broke it in the first place (but improved something)
(In reply to Eric Covener from comment #12) > The short patch is not conditional at all and has no specific connection to the > interaction with mod_dav so it may be good enough but probably the same could > have beeen said of whatever broke it in the first place (but improved > something) Thanks for looking into this, Eric! The best kinds of bugs are those that have already been fixed, right? > Does > https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directorycheckhandler > help here? It might... if &!*$-ing CentOS 7 wasn't stuck at v2.4.6! :-\ /me reaches for docker (which I'd have to do anyway to get ANY sort of fix, I know...)