.htaccess ne redirige pas correctement vers la page préfixée www

9

J'essaie de rediriger une URL sans www. à www.version (exemple.com à www.exemple.com). J'utilise l'habituel

RewriteCond %{HTTP_HOST} ^example\.com [nc]
RewriteRule (.*) http://www.example.com/$1 [R=301,L]

Cela fonctionne sur tous mes autres projets. Cependant sur ce site particulier, il se termine par une boucle de redirection. Voici la partie bizarre: j'ai essayé de boucler la version non www pour voir quels en-têtes elle envoie en utilisant curl --get http://example.com --dump-header domain.header > domain.html. Le fichier d'en-tête ressemblait à ceci:

HTTP/1.1 301 Moved Permanently
Date: Mon, 06 Jun 2011 14:45:16 GMT
Server: Apache/2.2.16 (Debian)
Location: http://example.com/
Vary: Accept-Encoding
Content-Length: 310
Content-Type: text/html; charset=iso-8859-1

Cependant, le fichier HTML résultant était le suivant:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.example.com/">here</a>.</p>
<hr>
<address>Apache/2.2.16 (Debian) Server at example.com Port 80</address>
</body></html>

(notez la différence d'adresse entre les fichiers) Quelqu'un sait-il comment résoudre ce problème (et qu'est-ce qui le provoque)? Toute autre directive de réécriture d'URL fonctionne correctement.

EDIT: le journal de réécriture contenait ceci: (le site est accessible à beaucoup de gens, donc le journal de réécriture est assez long, je ne suis pas sûr à 100% si c'est la bonne partie)

192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (3) [perdir /var/www/oup/81/] strip per-dir prefix: /var/www/oup/81/ ->
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (3) [perdir /var/www/oup/81/] applying pattern '(.*)' to uri ''
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (2) [perdir /var/www/oup/81/] rewrite '' -> 'http://www.example.com/'
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (2) [perdir /var/www/oup/81/] explicitly forcing redirect with http://www.example.com/
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (1) [perdir /var/www/oup/81/] escaping http://www.example.com/ for redirect
192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] [example.com/sid#b797f948][rid#b7d2c1c8/initial] (1) [perdir /var/www/oup/81/] redirect to http://www.example.com/ [REDIRECT/301]

La ligne du journal d'accès (probablement la bonne):

192.168.1.221 - - [06/Jun/2011:17:49:32 +0200] "GET / HTTP/1.1" 301 555 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.77 Safari/534.24"

La définition de l'hôte virtuel:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName example.com
        ServerAlias example.com www.example.com
        DocumentRoot /var/www/example/
        <Directory />
                Options FollowSymLinks
                AllowOverride All
        </Directory>
        <Directory /var/www/example/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride All
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

EDIT2: d' accord, je viens de comprendre que si je fais cela (démissionné et tenté de rediriger cela sans .htaccess):

//if clause determining that we're running on example.com and not www.example.com
header('HTTP/1.1 301 Moved Permanently');
header('Location: http://www.example.com' . $_SERVER['REQUEST_URI']);
header('Connection: close');

Cela provoque EXACTEMENT LA MÊME boucle de redirection. Sérieusement, c'est quoi ce bordel? Quelqu'un at-il une idée de ce qui pourrait éventuellement causer cela?

php  .htaccess  mod-rewrite  apache-2.2  http-headers 
— chiffrer
source
Avez-vous compilé vous-même Apache, ou? Il devrait être impossible que l'en-tête Location diffère de ce qui est dans la page car ils sont tirés de la même variable dans ce cas, donc c'est assez étrange. Je suppose que les demandes sont transmises directement à Apache, non, il n'y a pas d'autre serveur entre les deux?
— Tim Stone
Je n'ai pas compilé moi-même Apache et aucun autre serveur entre les deux.
votre serveur NS n'est probablement pas configuré correctement
— venimus
4
Il n'est pas nécessaire de répéter le nom du serveur dans l'entrée ServerAlias.
— chris
pouvez-vous mettre tout le contenu du fichier ici
— annulé

Réponses:

2

Ce qui me semble étrange, c'est la Location: http://domain.cz/ligne d'en-tête signalée par CURL. Vous ne redirigez jamais vers ce domaine. Le journal de redirection n'en contient aucune mention.

D'une manière ou d'une autre, l'en- Locationtête semble être modifié après que modrewrite ait fait son travail, et puisque vous avez également essayé de changer l'en-tête avec PHP, l'en- Locationtête est apparemment changé après le traitement de la demande. La seule explication à laquelle je peux penser est que vous modifiez l'en-tête d'emplacement avec mod_header quelque part.

Avez-vous vérifié tous les fichiers de configuration (httpd.conf, les fichiers .conf inclus et le fichier .htaccess) si vous trouvez quelque part une ligne similaire à celle-ci:

Header set Location (...)

ou

Header edit Location (...)
— Jakob Egger
source
Je n'ai rien trouvé de tel.
2
Vous connectez-vous directement à Apache, ou existe-t-il entre le cache ou un serveur proxy qui pourrait changer les en-têtes? La directive ProxyPassReverse peut également modifier l'en-tête d'emplacement ( httpd.apache.org/docs/2.0/mod/mod_proxy.html#ProxyPassReverse ).
il peut y avoir un proxy entre les deux, j'y jetterai un œil dès que je serai au travail demain.
@Jakob Egger - Je n'ai trouvé nulle part la directive ProxyPassReverse.
— chiffre
1

En plus d'activer la réécriture (si vous avez accès pour modifier httpd.conf), vous devez supprimer l'application qui réside sur ce site de l'équation. Supprimez / renommez temporairement le fichier index.php par défaut (ou la page d'index qui sert votre application) pour être sûr que cela ne cause pas cela.

Il existe de nombreux rapports d'applications (par exemple wordpress) qui font apparaître ces pages de redirection par défaut apache si elles sont mal configurées.

Vérifiez également le reste de la configuration d'apache pour voir s'il existe d'autres instructions de «redirection» qui pourraient être en conflit.

— Gavin C
source
L'application est correcte, je l'ai essayée sur un serveur différent et un domaine différent (copié toute l'application) et cela a bien fonctionné. Je suppose que c'est quelque chose dans la configuration Apache, mais je ne peux pas comprendre quoi.
L'application peut être correcte, mais peut également être en conflit avec la configuration sur ce serveur. Il semble que votre application soit actuellement en production, je peux donc voir à quel point la désactiver n'est pas idéale. Pour le plaisir, vous pouvez ajouter une chaîne de requête à la fin de la redirection comme indicateur pour faciliter la découverte - donc / $ 1? Nowww = 1 ou quelque chose de similaire.
— Gavin C
Non, ce n'est PAS en production.
Oh cool, alors ne peut pas faire de mal pour déplacer le fichier d'index à 100% l'exclure dans le cadre du problème :)
— Gavin C
Oh, bon sang, ce que je voulais écrire, c'est que c'est IS en production, je ne sais pas comment cela s'est produit :-)
0

Pouvez-vous essayer ce code alternatif mod_rewrite:

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
— anubhava
source
Cela a échoué exactement de la même manière.
pouvez-vous activer RewriteLog et voir ce qu'il crache.
— anubhava
Et comment puis-je faire exactement cela? :-)
Veuillez voir ici: httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewritelog La seule chose est que cette directive va dans la configuration apache PAS dans .htaccess.
— anubhava
1
J'ai copié la même règle (comme ma réponse ci-dessus) dans mon installation Apache et j'ai exécuté la même commande curl que vous avez dans votre question et j'ai fait Location: http://www.domain.com/partie de mes en-têtes donc dans mon cas, les en-têtes et html montrent tous les deux le même domaine, c'est-à-dire www.domain.com. Pouvez-vous également coller les lignes access.log pertinentes dans votre question ci-dessus?
— anubhava
0

pourriez-vous essayer d'utiliser [NC] au lieu de [nc], pourrait être si simple

— venimus
source
Et pourtant ce n'est pas :-) (déjà essayé, n'a pas fonctionné)
0

J'espère que vous avez accès au serveur, ajouté la ligne de redirection après le dossier de documents du site spécifié suivi 

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain\.cz [NC]
RewriteRule ^/(.*) http://www.domain.cz/$1 [L,R=301]

Si vous n'avez pas accès au serveur, ajoutez ces lignes sur httaccess en commençant / modifiez la partie.

Peut-être n'avez-vous pas ajouté "RewriteEngine on" avant la redirection.

J'ai ajouté RewriteEngine on, comme je l'ai dit, que cela fonctionne correctement sur un autre serveur, mais pas sur celui-ci.
AllowOverride All autorise de tous ajouter ces lignes dans votre fichier de configuration de serveur
0

Essayer:

RewriteCond %{HTTP_HOST} ^domain.cz [NC]
RewriteRule (.*) http://www.domain.cz/$1 [R=301,L]
— Shef
source
0

Assurez-vous de l'avoir Options +FollowSymLinkssi vous travaillez dans un contexte d'annuaire.

Sinon, si vous utilisez des hôtes virtuels basés sur le nom, essayez:

<VirtualHost *:80>
  ServerName domain.cz
  Redirect / http://www.domain.cz/
</VirtualHost>

<VirtualHost *:80>
  ServerName www.domain.cz
  # whatever else
</VirtualHost>
— chris
source
J'ai mis à jour la question avec la définition de VirtualHost.
Avez-vous essayé la solution VirtualHost multiple ci-dessus, ou êtes-vous prêt à utiliser mod_rewrite?
— chris
Au début, je ne voulais pas utiliser plusieurs VirtualHosts, mais étant donné les circonstances, je l'ai quand même essayé et cela n'a pas aidé.
0

Après avoir lu toutes les réponses, vous pouvez vérifier le fichier de / etc / hosts ... peut-être que toutes vos vérifications proviennent de votre ordinateur. Essayez d'accéder à partir d'un emplacement différent.

Non, rien dans les hôtes sur ce domaine.
0

J'ai une deuxième idée. Le journal du serveur que vous avez publié affiche une adresse "192.168.1.221", qui est une adresse du réseau local. Toutes les entrées de journal affichent-elles la même adresse IP? Si tel est le cas, il existe un proxy entre vous et le serveur. Ce proxy utilise probablement ProxyPassReverseou Header editpour changer l'en- Locationtête.

Il s'agit d'une configuration habituelle pour contourner le problème lorsque le serveur principal place son propre nom d'hôte dans l'en- Locationtête, plutôt que le nom d'hôte du serveur proxy externe.

S'il existe réellement un serveur proxy, vous devrez modifier la configuration du serveur proxy plutôt que la configuration du serveur principal, car le proxy remplacera toujours les informations.

Cela signifie que tout le temps nous avons regardé le mauvais serveur: Le problème est avec le serveur proxy!

— Jakob Egger
source
Demain, j'appelle le support technique de la société qui gère ce serveur. Je pense que ça doit être ça, je vais vous le faire savoir.
— chiffre
0

Il peut s'agir de caractères non imprimables comme null dans le .htaccessfichier.

hexdump -C .htaccess
— Charlie
source
0

Je crois qu'il vous manque un signe $ après votre condition de réécriture. S'il vous plaît essayez:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain.cz$
RewriteRule ^(.*)$ http://www.domain.cz/$1 [R=301,L]
— cormpadre
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.