MultiViews returns actual filename in headers

Exposing the technology?

[coopster]

Ever checked out Live HTTP headers for a site running MultiViews? Let's say you have a directory structure and the "services" listed here is actually a file, not a directory:

http://example.net/dir1/services/
http://example.net/dir1/services

The first link will return the following (relevant) headers:

HTTP/1.x 200 OK

... whereas a request for the filename itself returns the following (relevant) headers:

HTTP/1.x 200 OK 
Content-Location: services.php 
Vary: negotiate 
TCN: choice

Note the "Content-Location" header in particular. It's not that big of a deal, but let's say I didn't want the actual document name plus extension being leaked, how would I go about it? Any ideas? Direction? Cares, concerns?

[jdMorgan]

You could replace the multiviews function by using mod_rewrite with "file exists" and "directory exists" checking in RewriteConds IF the only reason you were using content negotiation was to implement extensionless files.

Something like:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(([^/]+/)*[^/.]+/?)$ /$1.php [L]

Note that the RewriteRule pattern is just a horribly-complicated way to prevent the original (.*) pattern from including a trailing slash if one is present in the requested path, as well as disabling the rule and preventing unneeded file-exists checks if the requested URL already contains a "." in the last part of the path.
Jim

[encyclo]

I've been looking at this problem from a few angles, and eventually I worked out a solution: you can suppress the

Content-Location

header using mod_headers [httpd.apache.org] without affecting the underlying negotiation process.

From the documentation, I first tried the following:

Header unset Content-Location

However this did not work as expected whatever I tried. Then I remember the negotiation process, and how the server handles a request when it is unable to decide the most appropriate file to serve. If the server has to offer a choice, it serves a document with a "300 Multiple Choices" response code. A "406 Not acceptable" response code could also be served if there are no appropriate candidates. The mod_headers directive states that:

This directive can replace, merge or remove HTTP response headers during 1xx and 2xx series replies. For 3xx, 4xx and 5xx use the ErrorHeader directive.

So I tried the following to take into account the possibility of the request leading to a 300 or 406 response:

[b]ErrorHeader unset Content-Location[/b]

Amazingly, it seems to work, and the page is still returned with a 200 OK response header. Don't ask me to explain the logic, though. ;)

[coopster]

It took me some time to get back to responding here. I just realized that I never did post my solution, which is quite easy. Almost all files on the server are invoking PHP, even if only for the top header, navigation, or footer. By naming all files with a .htm extension, the headers will report ...

HTTP/1.x 200 OK  
Content-Location: services.htm  
Vary: negotiate  
TCN: choice

... and then using an AddHandler to parse files with that extension as PHP works fine.

AddHandler php5-script htm