réécriture d'apache et variable de PHP REQUEST_URI

J'ai un problème avec Apache en passant à la PHP $_SERVER['REQUEST_URI'] l'URL après qu'elle a été réécrit plutôt que l'original demandé.

Je fais cette réécriture parce que j'avais un site Web wordpress et je voulais le déplacer vers un sous-directory plutôt que de l'avoir dans un path d'access racine, mais je voulais toujours que son URL soit l'URL racine. Cela ne se produit pas de façon constante. Si je request www.xyz.com/wp-admin il remplit la variable PHP REQUEST_URI avec www.xyz.com/wordpress/wp-admin (qui est l'URL après son réécriture), mais si je request www.xyz.com/wp-admin/ (avec une barre oblique), il remplit actuellement la variable PHP REQUEST_URI avec www.xyz.com/wp-admin/ (l'URL d'origine, avant la réécriture). Ce que je veux, c'est que REQUEST_URI soit rempli avec l'URL avant qu'il ne soit réécrit.

Mon file .htaccess est ci-dessous:

 <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?xyz.com$ RewriteCond %{REQUEST_URI} !^/wordpress/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ /wordpress/$1 RewriteCond %{HTTP_HOST} ^(www.)?xyz.com$ RewriteRule ^(/)?$ wordpress/index.php [L] </IfModule>` 

La version PHP est 5.3. La version Apache est 2.4 (Win32).

Mise à jour : je l'ai examiné plus et quand je tapez l'URL www.xyz.com/wp-admin puis il y a une redirection 301 d'abord sur www.xyz.com/wordpress/wp-admin/ mais cela ne se produit pas pour www.xyz.com/wp-admin/ (avec une barre oblique). Pour celui avec la barre oblique, il n'y a que la réécriture, comme prévu. La question maintenant est de savoir pourquoi la redirection 301 se produit en premier lieu pour l'URL sans la barre oblique. Pour clarifier, il n'y a pas de dossier réel /wp-admin/ , mais il existe un dossier /wordpress/wp-admin/ .

One Solution collect form web for “réécriture d'apache et variable de PHP REQUEST_URI”

Le "problème" est lié à mod_dir (bien que mod_dir ne soit pas ssortingctement "le" problème – il fait la bonne chose et "corrige" l'URL).

Étant donné que wp-admin est un directory physique, mod_dir "corrige" l'URL en ajoutant une barre oblique (requirejse pour bien servir l'index du directory, par exemple, index.php ). Il le fait avec une redirection 301. Le problème est que cela se produit après votre réécriture interne, ce qui fait que la réécriture est transformée en une redirection, exposant ainsi votre sous-directory /wordpress .

Ainsi, l'URL correcte est ssortingctement /wp-admin/ (avec une barre oblique). Si vous n'aviez pas votre sous-directory /wordpress et que tout se trouvait dans la racine du document, mod_dir redirectait simplement /wp-admin vers /wp-admin/ , ce qui entraînerait la mise en service /wp-admin/index.php (comme une sous-twig interne).

Ce que vous devez faire, c'est d'append la barre oblique manuelle manuellement. Si l'URL demandée ne se termine pas par une barre oblique, mais qui serait autrement cartographiée dans un directory physique dans le sous-directory /wordpress puis ajoutez la barre oblique (via une redirection externe). Cette redirection devrait se produire avant votre réécriture interne.

Essayez donc ce qui suit avant vos directives existantes:

 # Append a slash if it is omitted and would map to a directory RewriteCond %{REQUEST_URI} !^/wordpress/ RewriteCond %{REQUEST_URI} !/$ RewriteCond %{DOCUMENT_ROOT}/wordpress/$1 -d RewriteRule (.*) /$1/ [R=302,L] 

C'est ce que cela veut dire, pour toute request qui ne démarre pas /wordpress/ et ne se termine pas par une barre oblique, mais correspond à un directory physique dans le sous-directory /wordpress puis redirigez et ajoutez une barre oblique. Ainsi, une requête pour /wp-admin est redirigée /wp-admin/ , fournissant /wordpress/wp-admin existe en tant que directory. (Vos réécritures internes, puis apather l'URL comme précédemment.)

Vous devrez vous assurer que le cache de votre browser est effacé (ou testez avec l'inspecteur d'objects du browser ouvrir et désactiver le cache) car les 30i précédents (par mod_dir) seront mis en cache.

Lorsque vous êtes sûr que cela fonctionne correctement, modifiez la redirection 302 (temporaire) vers un 301 (permanent) – si c'est l'intention. Les 302 sont mis en cache par le browser, ce qui rend le test plus facile.

  • Réinitialisation de caractères generics du sous-directory nginx
  • Problème de réécriture d'URL
  • mediawiki et wordpress MU racine différente avec Nginx
  • règle mod_rewrite
  • IIS URL réécrit HTTP vers HTTPS avec port
  • L'état du serveur apache n'est pas trouvé. Vérifiez si mod_status est activé
  • Nginx reverse proxy forces 301 sur le sous-domaine (et il ne devrait pas)
  • htaccess réécrit le sous-domaine et request uri
  • nginx- Réécrire l'URL avec Slash de suivi
  • Réécriture d'URL dans IIS7
  • Utilisation des searchs RewriteMap dans RewriteCond. Possible?
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.