27

I'm having the following issue on a host using Apache 2.2.22 + PHP 5.4.0

I need to provide the file /home/server1/htdocs/admin/contents.php when a user makes the request: http://server1/admin/contents, but I obtain this message on the server error_log.

Negotiation: discovered file(s) matching request: /home/server1/htdocs/admin/contents (None could be negotiated)

Notice that I have mod_negotiation enabled and MultiViews among the options for the related virtualhost:

<Directory "/home/server1/htdocs">
    Options Indexes Includes FollowSymLinks MultiViews
    Order allow,deny
    Allow from all
    AllowOverride All
</Directory>

I also use mod_rewrite, with the following .htaccess rules:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^([^\./]*)$ index.php?t=$1 [L]
</IfModule>

It seems very strange, but on the same box with PHP 5.3.6 it used to work correctly. I'm just trying an upgrade to PHP 5.4.0, but I cannot solve this negotiation issue. Any idea on why Apache cannot match contents.php when asking for content (which should be what mod_negotiation is supposed to do)?

UPDATE: I noticed that mod_negotiation behaves correctly with files with extension different than .php: so if I'd have a file named /admin/contents.txt, I can access it regulary with the browser with /admin/contents url. So the problem is only for php files. Any clue on what could make the negotiation fail?

sgnsajgon
  • 121
  • 6
lorenzo.marcon
  • 1,027
  • 1
  • 11
  • 20

5 Answers5

46

I found the solution. Very easy, indeed. I forgot to include the following:

AddType application/x-httpd-php .php

into apache mod_mime section into httpd.conf

I was misled by the fact that php scripts were correctly working; however the negotiation was failing because mod_negotiation only looks for "interesting" (and known) file types.

lorenzo.marcon
  • 1,027
  • 1
  • 11
  • 20
  • 4
    This! This right HERE! Spent most of the night hunting down why I was getting the very unhelpful "Discovered File(s)/None Negotiated" error. Scripts had been working fine before, and I had a devil of a time tracking down the fact that the type wasn't being included in mod_mime on the distribution I was testing on. I owe you a beer sir. – Akoi Meexx Feb 19 '13 at 03:22
  • I'll gladly accept your beer when I'll come to US :) – lorenzo.marcon Feb 19 '13 at 10:21
  • this works perfectly!! @lorenzo.marcon thanks for the question and answer! – rogcg Jun 27 '13 at 01:50
  • This must have changed at some point. I'm feeling pretty confident I didn't need to add this earlier for php MultiViews to work. – user1338062 Sep 24 '13 at 15:44
  • Thanks a metric ton! I was banging my head against the wall, wondering why my mod rewrite from search/?$ to search.php wasn't working. Seems the negoitiation module has precedence over the rewrite module which is generally good to know. – zıəs uɐɟəʇs Oct 19 '18 at 11:25
  • Thanks I struggle for 2 hours, I would never have found ! – Emmanuel BRUNO Jul 06 '21 at 15:59
12

I had the same problem after updating from Debian Squeeze to Wheezy. The mods-enabled/mime.conf includes the known file types from the system:

TypesConfig /etc/mime.types

The problem was that the /etc/mime.types file was replaced by the update and in the replaced file, the PHP part was commented out. When searching for it, I found:

#application/x-httpd-php                        phtml pht php
#application/x-httpd-php-source                 phps
#application/x-httpd-php3                       php3
#application/x-httpd-php3-preprocessed          php3p
#application/x-httpd-php4                       php4
#application/x-httpd-php5                       php5

I had to remove the # from each line containing php-relevant stuff, then save and restart the Apache web server. That solved the problem without modifying the mime.conf file.

Ladadadada
  • 26,337
  • 7
  • 59
  • 90
derHippeChip
  • 121
  • 1
  • 2
  • This saved me after 4hs of unending debugging against a ghost. – MarkSkayff Jun 15 '18 at 00:47
  • 1
    Be aware that doing this might make `libapache-mod-php5` execute files with `.php` in the name (like `filename.php.jpeg`) which was the original rationale for commenting them out. See https://bugs.debian.org/589384 – Kevinoid Jul 08 '19 at 16:04
5

Instead of mapping .php to a media type (which can have security implications, as described in Debian Bug 589384 which disabled them), you can configure MultiviewsMatch to match files without a type for .php, as suggested in Mark Amery's answer to a similar question:

<Files "*.php">
    MultiviewsMatch Any
</Files>
Kevinoid
  • 171
  • 1
  • 5
2

I had the same problem after updating from Debian Squeeze to Wheezy. The mods-enabled/mime.conf includes the known file types from the system:

 TypesConfig /etc/mime.types

The problem was that the /etc/mime.types file was replaced by the update and in the replaced file, the PHP part was commented out. When searching for it, I found:

#application/x-httpd-php                        phtml pht php
#application/x-httpd-php-source                 phps
#application/x-httpd-php3                       php3
#application/x-httpd-php3-preprocessed          php3p
#application/x-httpd-php4                       php4
#application/x-httpd-php5                       php5

I had to remove the # from each line containing php-relevant stuff, then save and restart the Apache web server. That solved the problem without modifying the mime.conf file.

Andrew Schulman
  • 8,811
  • 21
  • 32
  • 47
0

I am working with Xammp with virtual hosts, the error with mod_rewrite was remove in httpd-vhosts.conf at <Directory "YourPath">

Instead

Options Indexes FollowSymLinks MultiViews

Put

Options Indexes FollowSymLinks

Source: https://www.lawebdelprogramador.com/foros/Apache/1422809-solucionado-Negotiation-discovered-files-matching-request.html

Greetings.

mariofertc
  • 101
  • 2