2

I have a bizarre problem that only (so far) manifests itself in Firefox, where it rewrites the URL to a different domain (also hosted by us). The rewrite however does not occur in Safari or Chrome (I'm testing from a MacBook Pro).

My setup is this: The loadbalancer running HAProxy listening on 80 an internally 8080 and Apache listening on 443. Traffic on 80 is passed to the backend, traffic from Apache is SSL decrypted then sent to localhost:8080 and then passed to the backend's port 8443. On the backend, any traffic from 80 is considered non-SSL, but on 8443 is considered decrypted SSL. Backend servers are running Apache.

If I go to https://www.sslexample.com/ (henceforth SSL_DOMAIN) from any browser on an SSL site, everything behaves as it should. It hits the Apache SSL accelerator, is decrypted, passed to the proxy, then sent to the backend. If I go to http://www.nonsslexample.com/ (henceforth NONSSL_DOMAIN), again, everything behaves as expected for a non-SSL site, it hits the proxy, then the backend, and non-SSL traffic is served as expected.

Here's where things get weird. If I go to SSL_DOMAIN via http, what's supposed to happen is that I'm redirected to https. For one of our mixed SSL/non-SSL domains, this works as expected from all browsers. BUT on Firefox (and sometimes on Safari for my colleague and never on Chrome) if I go to SSL_DOMAIN via http, the first thing that happens is that the URL is immediately rewritten to the NONSSL_DOMAIN and I'm redirected to the completely different domain.

Huh?

Looking at the logs on the LB, Chrome and Safari behave as they should--hit the lb on port 80--but Firefox never hits the loadbalancer with the SSL_DOMAIN on port 80. But the time to LB sees it, it's already been rewritten.

I installed the Tamper Data plugin on Firefox, and the results confused me more. The initial correct URL header never receives a reply header. It's immediately replaced with the incorrect one. And things carry on as if I had intended the non-SSL URL.

I looked in my /etc/hosts file (since this is in testing and we're overriding these domains), and everything looks correct.

If you have ever encountered a problem like this before, I'd be very grateful for tips on how to debug it.

4

1 回答 1

1

regilero 是对的。

我刚刚在 Mac OS X 10.9.1 上使用 Firefox 和 Safari 时遇到了同样的问题。他们似乎都缓存了 301 重定向，并在对曾经重定向的 URL 的下一个请求进行内部重写。

这很有趣，尤其是当您尝试在 Web 服务器配置中编写和测试重定向时。

我的解决方案是清空浏览器缓存。然后将再次从服务器读取重定向。每次我想再次阅读重定向时，我都必须这样做。

于 2013-12-29T03:24:59.333 回答