| Summary: | server-parsed documents served with additional path info | ||
|---|---|---|---|
| Product: | Apache httpd-1.3 | Reporter: | David Baron <dbaron> |
| Component: | mod_include | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | CLOSED WONTFIX | ||
| Severity: | normal | Keywords: | FAQ |
| Priority: | P3 | ||
| Version: | HEAD | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
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. (<http://httpd.apache.org/docs-2.0/mod/core.html#acceptpathinfo>) You may want to use mod_rewrite or similar to check for PATH_INFO and reject the request. Thanks for using Apache! 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. |
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: http://dbaron.org/log/2003-01 http://dbaron.org/log/2003-01/ http://dbaron.org/log/2003-01/aaaa (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.)