Apache2: 400 Bad Request avec Rewrite Rules, rien dans le journal des erreurs?

Ça me rend dingue.

Context: J'utilise Apache2 et PHP embedded avec Mac OS X 10.6

J'ai une configuration htelle comme suit:

NameVirtualHost *:81 <Directory "/Users/neezer/Sites/"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory> <VirtualHost *:81> ServerName lobster.dev ServerAlias *.lobster.dev DocumentRoot /Users/neezer/Sites/lobster/www RewriteEngine On RewriteCond $1 !^(index\.php|resources|robots\.txt) RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1 [L,QSA] LogLevel debug ErrorLog /private/var/log/apache2/lobster_error </VirtualHost> 

Ceci est dans /private/etc/apache2/users/neezer.conf .

Mon code dans le lobster project est PHP avec le cadre CodeIgniter . En essayant de charger http://lobster.dev:81/ me donne:

400 mauvaise request

Normalement, je vérifie mes journaux pour voir ce qui l'a provoqué, mais mes journaux sont vides! J'ai regardé dans les deux /private/var/log/apache2/error_log et /private/var/log/apache2/lobster_error , et aucun logging N'IMPORTE QUEL message concernant le 400. J'ai LogLevel défini pour debug dans /private/etc/apache2/http.conf .

La suppression des règles de réécriture se débarrasse de l'erreur, mais ces mêmes règles fonctionnent sur mon hôte MAMP. J'ai vérifié la checkbox et rewrite_modulerewrite_module est chargé dans mon installation par défaut d'Apache. Mon http.conf peut être trouvé ici: https://gist.github.com/1057091

Ce qui donne? Faites-moi savoir si vous avez besoin d'informations supplémentaires.

REMARQUE: Je ne souhaite pas append les règles de réécriture à .htaccess dans le directory du projet (il est vérifié dans un repo git et je ne veux pas le toucher).

3 Solutions collect form web for “Apache2: 400 Bad Request avec Rewrite Rules, rien dans le journal des erreurs?”

Pour des règles mod_rewrite compliquées, il est judicieux de consigner la séquence d'events pour voir ce qui se passe. Faites ceci en utilisant RewriteLog , et montrez le RewriteLogLevel pour voir les détails.

mod_rewrite est très flexible et on peut faire beaucoup de choses avec les règles de réécriture, et est également assez compliqué. Un outsider aura du mal à déboguer vos règles sans voir le context plus large. La meilleure chose que vous puissiez faire, déboguez-le par vous-même. Regardez les journaux dans une window pendant que vous expérimentez les modifications de configuration dans une deuxième window. Effectuez une petite modification, enregistrez le file, rechargez l'apache et appuyez à nouveau sur l'URL. Répéter.

Voici une bonne description de RewriteLog à partir du manuel Apache:

Réécrire le journal

Lorsque vous utilisez les fonctionnalités puissantes et complexes de mod_rewrite, il est presque toujours nécessaire d'utiliser RewriteLog pour faciliter le debugging. Ce file journal produit une parsing détaillée de la façon dont le moteur de réécriture transforme les requêtes. Le niveau de détail est contrôlé par la directive RewriteLogLevel.

Votre substitution dans le context <virtualhost> utilise une URL non absolue. Vous ne pouvez pas le faire en dehors du context Directory / htaccess.

Quelques autres notes, qui sont devenues un peu trop grandes pour être contenues dans un simple commentaire:

RewriteCond $1 fonctionne, mais c'est assez dangereux et fragile. En particulier, vous pourriez facilement réécrire le RewriteRule afin de désactiver complètement la fonctionnalité de RewriteCond, et vous ne savez jamais que vous l'aviez. L'utilisation de %{REQUEST_URI} est recommandée en tant que solution, à la RewriteCond %{REQUEST_URI} ^/(index\.php|resources|robots\.txt) .

Numéro suivant: ces deux lignes:

 RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d 

ne sont pas fonctionnels comme présenté. Ils doivent soit être placés dans une strophe <Directory> , soit modifiés pour utiliser les macros de look-ahead (p. Ex. RewriteCond %{LA-U:REQUEST_FILENAME} !-f ).

La cause réelle de votre besoin de supprimer le / est que .htaccess supprime le premier / du premier argument de RewriteRule, alors qu'il est livré avec / intact à RewriteRules dans httpd.conf (ou ses files Include d), ce qui est quelque chose d'important à retenir au cas où vous essayez de déplacer cette règle dans un .htaccess. Vous pouvez retravailler la règle pour être .htaccess / httpd.conf-agnostic en faisant quelque chose comme RewriteRule ^/?(.*)$ index.php/$1 [L,QSA] .

Une dernière note: comme vous pouvez le voir dans la règle ci-dessus, vous n'avez pas besoin d'échapper à la / avec une barre oblique inverse.

  • Meilleure pratique pour le deployment de PHP sur plusieurs servers
  • Comment réinstaller ou dégrader PHP sur Centos
  • PHP affiche le code source de la page dans le browser
  • Comment php sait-il le noeud memchached pour searchr ses données?
  • Apache n'interprète pas les fichiers .PHP
  • Envoi d'en-têtes HTTP par server Web ou PHP?
  • Les lignes longues Nginx / PHP-FPM sont tronquées
  • Erreur fatale: appel à une fonction indéfinie json_encode () ..?
  • Longs temps de connexion de PHP à MySQL sur EC2
  • Les nodej dépendent-ils des files apache common / util?
  • Est-ce sûr / comment mettre à jour php (5.3.9)? centos (6.5 final) et parallèles plesk panel (11.5.30 Mise à jour n ° 47)
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.