Bug 54914

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.