Apache Nettoyage des Url avec Multivues activé
Je suis en train de permettre le Nettoyage des Url, ayant Multivues activé.
Toutes les pages que j'ai, sont dans le dossier racine elle-même.
Je suis en train d'atteindre les objectifs suivants :
(current-status -> what I am trying to achieve)
1. foo.com/services.php -> foo.com/services
2. foo.com/services == foo.com/services/
3. foo.com/services.php/second-level/ == foo.com/services/second-level
La services
est pas un dossier, j'ai exploser $_SERVER['PATH_INFO']
et obtenez le deuxième niveau du chemin de données.
J'ai déjà réalisé la première, mais elle échoue lorsque j'active MultiViews
, à l'aide d'un .htaccess
fichier et écrire une réécriture.
Options +Indexes +FollowSymLinks -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) $1.php [L]
(Ce qui serait évidemment pas, car il faudrait modifier la demande de services/second-level.php).
Je sais que je peux écrire de multiples réécritures dans la .htaccess
, et à condition de redirection.
Mais le fait étrange est que sur le live de l'environnement (hébergement mutualisé), il est au travail, sans tout .htaccess
fichier dans le dossier racine. Depuis, c'est un hébergement mutualisé, je ne peut pas lire le fichier de configuration.
Toutes les idées sur quelle configuration dois-je changer (dans apache.conf
ou *.conf
) pour atteindre le plus haut?
Si il le faut, je suis en utilisant Apache/2.2.22
, et ce problème a commencé après la mise à jour.
- Je ne pense pas que vous voulez que cela:
foo.com/services.php -> foo.com/services
mais c':foo.com/services -> foo.com/services.php
. Il ne fait pas beaucoup de sens pour l'afficher dans le navigateur l'adresse d'un "vilain" de l'URL où la ressource est montré(foo.com/services.php)
, tout en cachant les "jolis" unfoo.com/services
, sauf quand il y a des raisons très spéciales. ¿Sont là? - Je veux Nettoyer URL elle-même. Juste mis à jour la question pour la rendre plus claire.
Vous devez vous connecter pour publier un commentaire.
J'ai enfin trouvé comment le résoudre.
Cela fonctionne, le retrait de la
.htaccess
fichier tout à fait, et la modification de laVirtual Directory
de garder les paramètres suivants :Cela m'aide à obtenir toutes les pages, exactement comme ils l'étaient de travail sur le serveur, sans les Réécrire Conditions.
Propre Url, sans .les extensions php, et sans l'aide de Multivues.
De flexibilité d'un environnement Web avec virtual sous-domaine de l'appui à l'aide de mod_userdir et mod_rewrite.
Permet à l'url suivante disposition
http://foo.bar/services.php/second-level/
http://foo.bar/services/second-level/
http://www.foo.bar/services/second-level/
http://127.0.0.1/services/second-level/
http://foo.bar/admin/login.php/foo
http://foo.bar/admin/login/foo
http://www.foo.bar/admin/login/foo
Note avec ou sans ajoutant www. est égal parce que www. est obsolète aujourd'hui...
Mais maintenant, vous pouvez hôte virtuel sous-domaines trop simplement par l'ajout d'un dossier dans
/var/www/sites/
(n'oubliez pas de DNS)http://images.foo.bar/imgpass.php/photo.jpg
http://images.foo.bar/imgpass/photo.jpg
http://www.images.foo.bar/imgpass/photo.jpg
http://127.0.0.1/~images/imgpass/photo.jpg
...et ainsi de suite, mais ignore si /var/www/sites/images/imgpass lui-même existe.
Je suis en utilisant un environnement multi-utilisateur, où chaque utilisateur a sa propre webroot et sous-domaine.
/etc/apache2/sites-enabled/foo.bar.conf:
Ce code n'est pas testet parce que mon système de fichiers de la structure diffère complètement du premier exemple.
Donc j'ai converti ma configuration à la volée pour s'adapter à cette structure exemple.
Remarque la configuration est incomplète. Vous devez régler vous-même à Vos besoins.
Tout Multivues peut être utilisé pour cela, ne pas ajouter l'arbitraire d'un type MIME pour les fichiers PHP de les amener à être servi par Multivues, comme le accepté de répondre à et de nombreuses autres sources sur internet suggèrent:
Ce hack, qui je l'explique dans le détail à https://stackoverflow.com/a/24598848/1709587, semble fonctionner, mais est en fait cassé; il échouera à chaque fois que le serveur reçoit une requête avec un
Accept
en-tête qui ne comprennent pas*/*
.Au lieu de cela, la solution propre est d'utiliser le
MultiviewsMatch
directive indique à Apache qu'il est valide pour servir.php
fichiers quel que soit leAccept
etAccept-Language
les en-têtes de la requête: