La négociation du fichier Apache a échoué

Je rencontre le problème suivant sur un hôte utilisant Apache 2.2.22 + PHP 5.4.0

Je dois fournir le fichier /home/server1/htdocs/admin/contents.phplorsqu'un utilisateur fait la demande:, http://server1/admin/contentsmais j'obtiens ce message sur le serveur error_log.

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

Notez que j'ai mod_negotiationactivé et MultiViews parmi les options pour l'hôte virtuel associé:

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

J'utilise également mod_rewrite, avec les .htaccessrègles suivantes :

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

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

Cela semble très étrange, mais sur la même boîte avec PHP 5.3.6, cela fonctionnait correctement. J'essaie simplement une mise à niveau vers PHP 5.4.0, mais je ne peux pas résoudre ce problème de négociation. Une idée sur pourquoi Apache ne peut pas correspondre contents.phplors de la demande content(quelle devrait être la fonction de mod_negotiation)?

MISE À JOUR: J'ai remarqué que mod_negotiation se comporte correctement avec des fichiers avec une extension différente de .php: donc si j'avais un fichier nommé /admin/contents.txt, je peux y accéder régulièrement avec le navigateur avec / admin / contents url. Le problème concerne donc uniquement les fichiers php. Un indice sur ce qui pourrait faire échouer la négociation?

apache-2.2 php

— lorenzo.marcon
source

Comment configurez-vous mod_negotiation? L'utilisez-vous?

— Mircea Vutcovici

Eh bien, j'inclus juste mod_negotiation dans httpd.conf, alors les options MultiViews dans VirtualHost devraient être suffisantes pour faire ce que je recherche, pour autant que je sache .. n'est-ce pas?

— lorenzo.marcon

FWIW, j'ai eu ce problème avec +MultiViewsactivé, et il a disparu en le désactivant.

— Felix Frank

Réponses:

J'ai trouvé la solution. Très facile, en effet. J'ai oublié d'inclure les éléments suivants:

AddType application/x-httpd-php .php

dans la section apache mod_mime dans httpd.conf

J'ai été induit en erreur par le fait que les scripts php fonctionnaient correctement; cependant, la négociation a échoué car mod_negotiation ne recherche que les types de fichiers "intéressants" (et connus).

— lorenzo.marcon
source

Cette! Ce droit ICI! J'ai passé la majeure partie de la nuit à chercher pourquoi j'obtenais l'erreur très inutile "Fichier (s) découvert (s) / Aucun négocié". Les scripts fonctionnaient bien auparavant, et j'ai eu un diable de temps à retrouver le fait que le type n'était pas inclus dans mod_mime sur la distribution sur laquelle je testais. Je te dois un monsieur de bière.

— Akoi Meexx

J'accepterai volontiers votre bière quand je viendrai aux États-Unis :)

— lorenzo.marcon

cela fonctionne parfaitement !! @ lorenzo.marcon merci pour la question et la réponse!

— rogcg

Cela a dû changer à un moment donné. Je me sens assez confiant que je n'avais pas besoin d'ajouter cela plus tôt pour que php MultiViews fonctionne.

— user1338062

Merci une tonne métrique! Je me cognais la tête contre le mur, me demandant pourquoi mon mod de réécriture de search /? $ Vers search.php ne fonctionnait pas. Il semble que le module de négociation ait la priorité sur le module de réécriture qui est généralement bon à savoir.

— zıəs uɐɟəʇs

J'ai eu le même problème après la mise à jour de Debian Squeeze vers Wheezy. Le mods-enabled/mime.confinclut les types de fichiers connus du système:

TypesConfig /etc/mime.types

Le problème était que le /etc/mime.typesfichier a été remplacé par la mise à jour et dans le fichier remplacé, la partie PHP a été commentée. Lors de la recherche, j'ai trouvé:

#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

J'ai dû supprimer le #de chaque ligne contenant des informations pertinentes pour PHP, puis enregistrer et redémarrer le serveur Web Apache. Cela a résolu le problème sans modifier le mime.conffichier.

— derHippeChip
source

Cela m'a sauvé après 4h de débogage sans fin contre un fantôme.

— MarkSkayff

Sachez que cela pourrait faire libapache-mod-php5exécuter des fichiers avec .phple nom (comme filename.php.jpeg) qui était la raison originale pour les commenter. Voir bugs.debian.org/589384

— Kevinoid

Au lieu de mapper .phpsur un type de média (ce qui peut avoir des implications sur la sécurité, comme décrit dans le bogue Debian 589384 qui les a désactivés), vous pouvez configurer MultiviewsMatchpour faire correspondre les fichiers sans type pour .php, comme suggéré dans la réponse de Mark Amery à une question similaire :

<Files "*.php">
    MultiviewsMatch Any
</Files>

— Kevinoid
source