Firefox réécrit mystérieusement, mais pas les autres navigateurs

J’ai un problème bizarre qui ne se manifeste (jusqu’à présent) que dans Firefox, où il réécrit l’URL sur un autre domaine (également hébergé par nous). La réécriture ne se produit toutefois pas dans Safari ou Chrome (je teste depuis un MacBook Pro).

Mon installation est la suivante: le loadbalancer exécute HAProxy en écoutant 80 8080 en interne et Apache en écoutant 443. Le trafic sur 80 est transmis au serveur principal, le trafic Apache est déchiffré SSL, puis envoyé à localhost: 8080 puis transmis au port 8443 du serveur principal. Sur le backend, tout trafic provenant de 80 est considéré comme non SSL, mais sur 8443, il est considéré comme SSL déchiffré. Les serveurs principaux exécutent Apache.

Si je vais sur https://www.sslexample.com/ (désormais SSL_DOMAIN) depuis n’importe quel navigateur sur un site SSL, tout se comporte comme il se doit. Il accède à l’accélérateur SSL Apache, est déchiffré, transmis au proxy, puis envoyé au serveur principal. Si je vais sur http://www.nonsslexample.com/ (désormais NONSSL_DOMAIN), encore une fois, tout se comporte comme prévu pour un site non-SSL, il frappe le proxy, puis le backend et le trafic non-SSL est servi comme prévu. .

Voici où les choses deviennent étranges. Si je vais sur SSL_DOMAIN via http, ce qui est censé arriver est que je suis redirigé vers https. Pour l’un de nos domaines SSL / non SSL mixés, cela fonctionne comme prévu dans tous les navigateurs. MAIS sur Firefox (et parfois sur Safari pour mon collègue et jamais sur Chrome) si je vais sur SSL_DOMAIN via http, la première chose qui se passe est que l’URL est immédiatement réécrite dans NONSSL_DOMAIN et que je suis redirigé vers le domaine complètement différent.

Hein?

En regardant les journaux sur la LB, Chrome et Safari se comportent comme ils le devraient: appuyez sur lb sur le port 80, mais Firefox ne frappe jamais le loadbalancer avec SSL_DOMAIN sur le port 80. Mais le temps de LB le voit, il a déjà été réécrit .

J’ai installé le plugin Tamper Data sur Firefox, et les résultats m’ont encore plus perturbé. L’en-tête URL correct initial ne reçoit jamais un en-tête de réponse. Il est immédiatement remplacé par le mauvais. Et les choses continuent comme si j’avais prévu l’URL non-SSL.

J’ai regardé dans mon fichier / etc / hosts (puisque cela est en cours de test et que nous remplaçons ces domaines), et tout semble correct.

Si vous avez déjà rencontré un problème comme celui-ci auparavant, je vous serais très reconnaissant de trouver des astuces pour le déboguer.

regilero a raison

Je viens de rencontrer le même problème avec Firefox et Safari sur Mac OS X 10.9.1. Ils semblent tous deux mettre en cache les redirections 301 et réécrire en interne lors de la requête suivante à l’URL redirigée.

C’est assez amusant, surtout si vous essayez d’écrire et de tester des redirections dans votre configuration de serveur Web.

La solution pour moi était de vider le cache du navigateur. Ensuite, la redirection sera relue depuis le serveur. Je devais le faire chaque fois que je voulais que la redirection soit relue.