Bug 16595 - server-parsed documents served with additional path info
Summary: server-parsed documents served with additional path info
Alias: None
Product: Apache httpd-1.3
Classification: Unclassified
Component: mod_include (show other bugs)
Version: HEAD
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FAQ
Depends on:
Reported: 2003-01-30 14:07 UTC by David Baron
Modified: 2004-11-16 19:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description David Baron 2003-01-30 14:07:19 UTC
Documents using the server-parsed handler are incorrectly served (instead of
giving a 404 error) when the URL for the server-parsed page has a / appended to
it, perhaps followed by additional characters.  This is a problem mainly because
it serves the document in a form that breaks relative URLs and server-side includes.

Steps to reproduce:
 Create an .htaccess file with:
    AddType "text/html; charset=iso-8859-1" .abug
    AddHandler server-parsed .abug
 and create a simple foo.abug file in that directory.

Actual results:
  http://server/dir/foo.abug , http://server/dir/foo.abug/ , and
  http://server/dir/foo.abug/bar all return the document.

Expected results:
  Only the first of the three URLs should return the document.

This bug can be seen on a live server (which uses "Options +MultiViews") at:

(Users of my pages are occasionally confused by the fact that I use MultiViews
and don't use extensions in my URLs.  This is, after all, good practice:
http://www.w3.org/Provider/Style/URI.html .  However, occasionally users think
the URL is a directory, since it lacks an extension, and add a slash to the end.
 This problem has been pointed out to me a number of times over the past few
years, so I'm finally breaking down and filing a bug despite not having tested
it on the very latest version of Apache (or on Apache 2.0, for that matter),
since I'm not running my own server and don't have the time to set one up just
to test this bug.)
Comment 1 André Malo 2003-01-30 15:01:43 UTC
Yes, it's a known issue. There were a lot of discussion about SSI and path info
in the past. However, these resulted in the behaviour in Apache 2.x, were SSI
(resp. the core handler) rejects all path info by default and has to be
explicitely turned on.

You may want to use mod_rewrite or similar to check for PATH_INFO and reject the

Thanks for using Apache!
Comment 2 William A. Rowe Jr. 2003-01-30 15:57:42 UTC
  To be very precise, AcceptPathInfo Default causes the path info to be accepted
  by the corresponding handler by it's specific preference.

  So most content generators, such as CGI, PHP, and SSI (because SSI may nest 
  other generators) default to accepting path info.  The core static content
  handler defaults to rejecting path info.  But any of these may be overriden
  with AcceptPathInfo to tollerate or reject such requests.

  For disambigiating URIs I strong believe in setting AcceptPathInfo Off within
  the root of the server, and setting up AcceptPathInfo On only for the scripts
  and content which *uses* the path info (e.g. a viewcvs.cgi style script.)
  But that's religion and advocacy.  In order to prevent *breaking* all of the
  deployed 1.3.x servers as they migrated to 2.0.x, the team elected to keep
  the behavior as similar as possible to Apache 1.3's behavior.