Closed Bug 618447 Opened 14 years ago Closed 14 years ago

Non-Firefox users who visit http://nova.stage.mozilla.com/ are directed to the Firefox version

Categories

(www.mozilla.org :: General, defect)

x86
macOS
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: retornam, Assigned: abuchanan)

Details

(Whiteboard: [redesign])

Attachments

(1 file)

1) Users of  IE,Opera and chrome who visit http://nova.stage.mozilla.com/ are directed to  http://nova.stage.mozilla.com/en-US/firefox/fx/ which is the Firefox  landing page
Whiteboard: [redesign]
Weird - this was *just* working for me and now it's not.
Also, I tried to reach the site via Firefox 4 Beta 7 and the status spinner on the tab won't stop spinning even when the page has finished loading.
Assignee: nobody → abuchanan
I can't reproduce this bug.

(In reply to comment #2)
> Also, I tried to reach the site via Firefox 4 Beta 7 and the status spinner on
> the tab won't stop spinning even when the page has finished loading.

Let's not mix issues please.  File a separate bug.  (Also, I can't reproduce that)
There was a brief window where a mistake in the .htaccess file was committed before the fix and all browsers were being redirected to /fx/, but I can't replicated it this now that the fix is in.

Marking as fixed - reopen if reproduced.
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: qawanted
Resolution: --- → FIXED
It's fixed in Chrome, but when I try in Safari it's still happening. Maybe I should wait a minute for the fix to kick in?

Also, if I visit http://nova.stage.mozilla.com/en-US/firefox in Firefox it still redirects me to the panda page. It's not essential for now, but it would be nice to be able to go to that page if I enter it in directly (much like the way http://www.mozilla.com/en-US/firefox/ie.html is now).

Lastly, I want to make sure we have the correct behavior set here - people on 3.6 should see the panda page, but older Firefox users should see the page with the download button.

Thanks-
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #5)
> It's fixed in Chrome, but when I try in Safari it's still happening. Maybe I
> should wait a minute for the fix to kick in?

Safari might have cached the redirect? I can't reproduce it here in Safari. Maybe confirm on another machine, or clear out cache/etc?

> Also, if I visit http://nova.stage.mozilla.com/en-US/firefox in Firefox it
> still redirects me to the panda page. It's not essential for now, but it would
> be nice to be able to go to that page if I enter it in directly (much like the
> way http://www.mozilla.com/en-US/firefox/ie.html is now).

Ah, right - this is a side-effect of not redirecting everyone to a non-default URL. I'll update the bug with more details/options on the weekend.

> Lastly, I want to make sure we have the correct behavior set here - people on
> 3.6 should see the panda page, but older Firefox users should see the page with the download button.

I haven't tested this yet, but that is indeed the intention of what we have setup now.
(In reply to comment #6)
> Safari might have cached the redirect? I can't reproduce it here in Safari.
> Maybe confirm on another machine, or clear out cache/etc?

Yep...I cleared the cache in Safari and it works fine now - thanks.
 
> Ah, right - this is a side-effect of not redirecting everyone to a non-default
> URL. I'll update the bug with more details/options on the weekend.

Thanks. This definitely isn't a blocker, so please prioritize accordingly. (We can always address this after the launch, that is.)
 
> > Lastly, I want to make sure we have the correct behavior set here - people on
> > 3.6 should see the panda page, but older Firefox users should see the page with the download button.
> 
> I haven't tested this yet, but that is indeed the intention of what we have
> setup now.

Actually, now when I visit the nova site in Fx4 I'm not redirected at all! I'm seeing the regular old download page again. Is that an easy fix?
(In reply to comment #7)
> Actually, now when I visit the nova site in Fx4 I'm not redirected at all! I'm
> seeing the regular old download page again. Is that an easy fix?

Ok, now it's working. Things have been pretty back & forth on this today...Raymond, please check the redirect situation here as thoroughly as possible. It's *very* important to get this right.
I just visited http://nova.stage.mozilla.com for the first time in both Chrome and Safari, and in both instances, it redirected to http://nova.stage.mozilla.com/en-US/firefox/fx/ .
(In reply to comment #9)
> I just visited http://nova.stage.mozilla.com for the first time in both Chrome
> and Safari, and in both instances, it redirected to
> http://nova.stage.mozilla.com/en-US/firefox/fx/ .

Hmm...same for me. The fact that this keeps switching back & forth between being right and wrong makes me nervous. I really can't overstate how important it is to get this right. We absolutely can't launch if people who don't have Fx are seeing the panda page instead of the download page.
Severity: normal → blocker
Works sometimes, but not always... sounds like a classic caching bug to me.
BTW, I can reproduce this bug now.
Also, everything works as expected when I test on my dev. site.  My dev. site doesn't have our Zeus caching layer in front of it.  Meaning, more evidence that this is a caching problem.
These are the headers corresponding to the redirect for Fx 3.6+ users:


HTTP/1.1 302 Found
Server: Apache/2.2.3 (Red Hat)
Cache-Control: max-age=900
Content-Type: text/html; charset=iso-8859-1
Date: Sat, 11 Dec 2010 02:27:41 GMT
Location: http://nova.stage.mozilla.com/en-US/firefox/fx/
Keep-Alive: timeout=5, max=1000
Expires: Sat, 11 Dec 2010 02:42:41 GMT
Accept-Ranges: bytes
Content-Length: 319
Connection: Keep-Alive
X-Cache-Info: cached



The problem there is Cache-Control.  It needs to look more like this:

Cache-Control: private, no-store, no-cache, max-age=0, must-revalidate, proxy-revalidate

Also, I think we'd need to add Vary: User-Agent

After a fix has been implemented, we'll need IT to dump the Zeus cache.
I think we should consider redirecting both groups of users to a unique URL.

Currently:

* chrome user hits /firefox/
* a page is returned (and therefore cached in Zeus)
* different, firefox user hits /firefox/
* the request hits Zeus, Zeus finds a cached page, and returns that, incorrectly

The same can happen for the redirect, it just depends on what gets cached first.  That's why we'd need Vary: User-Agent under the current setup.


Proposal:

* chrome user hits /firefox/
* user is redirected to /firefox/nonfx/ (or whatever url you want)

* different, firefox user hits /firefox/
* user is redirected to /firefox/fx/


That should avoid caching issues, I think, and avoid Vary: User-Agent


Anyway, I'll patch this tomorrow.
That sounds like a good solution to me. Let's use /new/ instead of /nonfx/, though...I like URLs that remind us what the case is, but don't make the user feel like they're obviously being targeted.
Keywords: qawanted
(In reply to comment #16)
> That sounds like a good solution to me. Let's use /new/ instead of /nonfx/,
> though...I like URLs that remind us what the case is, but don't make the user
> feel like they're obviously being targeted.

I had hoped to avoid a redirect for one of the groups by keeping them on the original URL, but I agree that it's nice to be able to go directly to either page with the direct URL in any browser.
When I visit the site with IE7, I get redirected to the FX page, and what's more, it does not render correctly.
User agent
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C)
r79326 and r79327 fix this.
Keywords: qawanted
(In reply to comment #20)
> r79326 and r79327 fix this.

I should note, that I moved this detection/redirection from .htaccess -> includes/prefetch.php.  That could allow to use the version numbers from product-details to automatically update the redirects for /firefox/fx/
qa-verified-trunk in IE/Chrome/Firefox/Safari http://nova.stage.mozilla.com/
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Keywords: qawanted
Resolution: --- → FIXED
Alex, can we remove en-US/firefox/index.html from the SVN repo?
(In reply to comment #23)
> Alex, can we remove en-US/firefox/index.html from the SVN repo?

Yes
verified fixed on  http://www.mozilla.com/en-US/firefox/ in IE/Safari/Chrome
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: