Closed Bug 752232 Opened 8 years ago Closed 8 years ago

mozilla.com redirects improperly on https (:443)

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task, critical)

task
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: morgamic, Assigned: nmaul)

References

Details

https://mozilla.com/ is displaying student reps content, which is totally weird/random.

See:
https://www.mozilla.com/en/

We should fix this soon.  I won't make this a blocker, but we should fix it ASAP next week.
Blocks: 752178
Summary: mozilla.com redirect improperly on https (:443) → mozilla.com redirects improperly on https (:443)
Blocks: 752161
This also causes manual plugin update checks through the addon manager in shipping firefox to 404, not very helpful to our users (bug 752161). This should be fixed ASAP.
Severity: normal → critical
OS: Other → All
Assignee: server-ops → rbryce
I'm also looking into this.
I believe this is fixed now. Please let me know if you see any further oddities. One thing I see that we'll need to clean up is that it's not preserving the protocol on redirect right now. But, at least it's redirecting to the proper place.


As far as I can tell, this is an old bug that has only recently been made visible. The fix will explain it more succinctly than I can:

--- www.mozilla.com-svn.conf	(revision 20361)
+++ www.mozilla.com-svn.conf	(working copy)
@@ -1,5 +1,5 @@
 # vim: syntax=apache
-<VirtualHost *:80>
+<VirtualHost *:80 *:81>


That's it. The mozilla.com / www.mozilla.com VirtualHost was not listening on port 81, so something else was taking that traffic. The Apache config was last changed on 2011-09-07, and we're only just now encountering this. This tells me that either SSL traffic wasn't getting passed to the backend on port 81 but instead used port 80, or some other VirtualHost was until recently acting as the global VirtualHost for all unmatched port 81 traffic and just happened to have some suitable content or redirect in place, and nobody noticed a problem. The former is more likely, but I'm still trying to track down what exactly happened.
Assignee: rbryce → nmaul
(In reply to Jake Maul [:jakem] from comment #3)
> One thing I see that we'll need to clean up is that it's not
> preserving the protocol on redirect right now.

This actually does work... I was looking at the HTML response and not the actual Location: header. Zeus alters the header, but doesn't bother with fixing the HTML body.

In any case, I've reorganized the Apache config files on our end to do this better and not rely on Zeus to do this for us. Everything else we have relies on Apache to get it right in the first place, so that's what we do here now too.
Seems to be fixed now. Thanks Jake! Time to close this bug?
I'm waiting for a call from someone that'll help me track down what changed (maybe). Going to keep this open for a little while, in the hopes that I can add a definitive cause.
Appears fixed here too. Thanks!
The cause of this has been determined.

DNS for mozilla.com and www.mozilla.com was only recently (Friday) changed from SJC1 to PHX1, as part of the ongoing datacenter migrations. I had thought it was done quite a while ago, so I hadn't checked our DNS config history.

In SJC1 the load balancers appear to have been configured to route HTTP and HTTPS traffic to the same backend port. In PHX1, this was not the case... but the Apache configs between the two locations are identical. When PHX1 became primary, the underlying bug became visible.

The old SJC1 config was non-standard, which was a contributing factor to this being overlooked. PHX1 is done properly (or at least, according to our conventions... which is just as good in this type of situation).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 752178
No longer blocks: 752178
Blocks: 788259
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.