Bug 25435 - sethandler and directoryindex not playing nice
Summary: sethandler and directoryindex not playing nice
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.0.54
Hardware: All Linux
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2003-12-11 11:21 UTC by Jon keller
Modified: 2018-11-07 21:09 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Jon keller 2003-12-11 11:21:53 UTC
I've notived that when invoking sethandler to do things like enable modperl in a
<directory> container, DirectoryIndex no longer works.

I ran into this problem when a upgrading from 1.3 to 2.0 using the fedora core1 
apache 2.0 rpms, this used to work fine with 1.3

If I replace the sethandler with a addhandler and a file extention then 
directoryindex starts working again. However this is not a useful fix for me as 
my modperl directory contains scripts which have no file extentions for url 
Comment 1 Joshua Slive 2003-12-11 14:20:25 UTC
A specific configuration example always helps.
Comment 2 Jon keller 2003-12-11 22:35:49 UTC
Sure, sorry

Alias /admin /var/www/perl
<Directory /var/www/perl>
    SetHandler perl-script
    DirectoryIndex index.pl panel
    PerlHandler ModPerl::Registry
    Options Indexes +ExecCGI FollowSymLinks

when /admin is accessed i get a 404 error, with this in the error log
[Thu Dec 11 23:53:58 2003] [error] [client] Attempt to serve 
directory: /var/www/perl/

if i access /admin/panel it works fine

For the sake of testing i copied panel to a file called index.pl
I replaced the Sethandler command with the 'Addhandler perl-script .pl' command
DirectoryIndex started working again and /admin works on its own. however 
my /admin directory is full of scripts without file extentions, these files 
need to be run without extentions.

thank you
Comment 3 Jon keller 2003-12-12 00:29:03 UTC
I'd also like to add that this exact configuration worked fine in apache 1.3.

Comment 4 Gene Pavlovsky 2005-07-08 12:41:42 UTC
I've got the same problem when using SetHandler for my PHP files. I've checked
the server error log files and it seems that the new apache tries to execute the
directory itself with mod_php, which obviously files, so I get an error. I've
worked around this by the following config, but the bug should be fixed.

    <Directory "/var/www/localhost/htdocs/forum">
        DirectoryIndex list
        <Files "?*">
            SetHandler application/x-httpd-php

This works because Files "?*" doesn't match the directory itself.
Comment 5 Paul Querna 2005-08-18 21:57:13 UTC
I can easily reproduce this with CGIs too:

DirectoryIndex index
<Directory /var/foo>
  SetHandler cgi-script

Where /var/foo/index is a cgi script, we get the 'attempt to invoke directory as

I suspect that mod_dir is never attempting to find the index, and lets mod_cgi
handle it, which means it is never being mapped from the / to /index internally...
Comment 6 Paul Querna 2005-08-18 22:11:08 UTC
Fixed in trunk/r25435.
Comment 7 William A. Rowe Jr. 2005-08-22 17:55:19 UTC
  FYI - although it's noted that this is 'fixed in trunk' - that patch was
  backed out.

  Here's the problem; httpd/unix-directory (DIR_MAGIC_TYPE) is the handler 
  name for mod_dir/mod_autoindex.  When you told the server to substitute using
  SetHandler - you told it the whole shot, dir files and all.

  You mentioned mod_perl however; if you are not allowed to override the
  handler, you can't replace the mod_dir/mod_autoindex handling with a module
  of your own design.  The proposed 'fix' would have ignored the handler name
  for directory uri's, and that's an inappropriate fix.

  For 2.2, especially, what about a SetFileHandler directive to apply
  on to any 'file' type, and a SetDirHandler directive to apply only to any
  'directory' type?

  There may also be some issues where we are toggling r->handler, that aren't
  in an appropriate location.  I'd guess we should be setting up the r->handler
  in the MapToStorage hook, right after the TranslateName hook is done.

  Anyways, allowing SetHandler to change the handler for directory resources
  is absolutely by design; otherwise mod_jk, mod_aspdotnet and other back end
  engines would not be allowed to perform their own directory resource handling.
Comment 8 André Malo 2005-08-22 18:34:42 UTC
+1 to type specific handlers. I would add an option to Sethandler though (vs.
adding new directives), like

# for all:
Sethandler foo

# for files:
SetHandler files foo

# for dirs
SetHandler dirs foo
Comment 9 William A. Rowe Jr. 2005-08-22 18:49:00 UTC
The workaround is

  <Files "*">
      SetHandler my-handler

(Files won't be applied to a directory), so the bug is non-critical.

The reason nd's suggestion doesn't quite work, is that SetHandler will
always work, it's a Location handler that doesn't depend on any file system
underneath it.

The SetFileHandler/SetDirHandler would be handled by the apache filesystem
core, and not the apache core uri handler, so an overloaded directive doesn't
work in this case.

The theory-to-be is that we should someday be able to unplug the filesystem 
core, and still have a useful apache which can serve other forms of
non-filesystem based content, such as a pure jk, pure proxy, or pure php server.

Comment 10 Paul Querna 2005-11-02 16:46:20 UTC
*** Bug 37290 has been marked as a duplicate of this bug. ***
Comment 11 Andreas Krüger 2009-01-02 12:54:42 UTC
For what it's worth, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451714 seems to be a duplicate of this bug.
Comment 12 William A. Rowe Jr. 2018-11-07 21:09:50 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.