Bug 25435

A specific configuration example always helps.

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
</Directory>

when /admin is accessed i get a 404 error, with this in the error log
[Thu Dec 11 23:53:58 2003] [error] [client 203.118.169.214] 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

I'd also like to add that this exact configuration worked fine in apache 1.3.

thanks

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
        </Files>
    </Directory>

This works because Files "?*" doesn't match the directory itself.

I can easily reproduce this with CGIs too:

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

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

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...

Fixed in trunk/r25435.

  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.

+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

The workaround is

  <Files "*">
      SetHandler my-handler
  </Files>

(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.

*** Bug 37290 has been marked as a duplicate of this bug. ***

For what it's worth, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451714 seems to be a duplicate of this bug.

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.