Closed Bug 591335 Opened 15 years ago Closed 15 years ago

Mobile link for Alpha 1 fails to redirect correctly

Categories

(mozilla.org Graveyard :: Server Operations, task)

x86
macOS
task
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mfinkle, Assigned: aravind)

Details

Attachments

(1 file)

When trying to download the latest Fennec alpha, we send users to http://www.mozilla.com/m/alpha, which will redirect to a locale specific url (http://www.mozilla.com/fr/m/alpha for example) When trying to download the alpha we get a 404. Only http://www.mozilla.com/en-US/m/alpha seems to work.
Usually if there's no content in mozilla.com/%LOCALE%/* we fall back to en-US; the problem is that's not happening here. Any idea why?
To be clear: there's no content in www.mozilla.com/%LOCALE%/m/alpha for any locale other than en-US, yet it's not falling back to the en-US content properly.
Beltzner asked me to take a look at this. Sounds like redirect issues, can IT take a look at what's there please?
Assignee: nobody → server-ops
Component: www.mozilla.com → Server Operations
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → mrz
Version: unspecified → other
Assignee: server-ops → jlazaro
Question for mfinkle/whoever: did this ever work?
Vhost: > # vim: syntax=apache > <VirtualHost *:80> > ServerName www.mozilla.com > ServerAlias *.www.mozilla.com www.stage.mozilla.com www-stage.mozilla.com *.www.stage.mozilla.com *.www-stage.mozilla.com www-mozilla-com.glb.mozilla.com sjc.mozilla.com ams.mozilla.com mozcom-cdn.mozilla.net > ServerAdmin webmaster@mozilla.com > DocumentRoot /data/www/www.mozilla.com-svn > AddType application/x-httpd-php .php .html > DirectoryIndex index.php index.html > RewriteEngine On > RewriteMap toupper int:toupper > SetEnvIf SSLSessionID .+ HTTPS=on > #RewriteCond %{HTTP:Moz-Req-Method} ^HTTPS$ [NC] > #RewriteRule ^.*$ - [env=HTTPS:on,env=force-no-vary:hellsyes] > > <Directory "/data/www/www.mozilla.com-svn"> > Options MultiViews FollowSymLinks -Indexes > AllowOverride All > ExpiresActive on > ExpiresDefault "access plus 15 minutes" > Options +MultiViews -Indexes > </Directory> > > > > <LocationMatch ^/en-US(/projects)?/firefox(/(index.html)?)?$> > ExpiresActive off > Header always set "Cache-Control" "no-store, no-cache, must-revalidate, post-check=0, pre-check=0, private, max-age=0" > Header always set "Pragma" "no-cache" > </LocationMatch> > > <LocationMatch /en-US/firefox/ie.html> > ExpiresActive off > Header always set "Cache-Control" "no-store, no-cache, must-revalidate, post-check=0, pre-check=0, private, max-age=0" > Header always set "Pragma" "no-cache" > </LocationMatch> > > > > SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" is-forwarded > LogFormat "%h %v %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\"" urchin > ErrorLog "|/usr/sbin/rotatelogs /var/log/httpd/www.mozilla.com/error_log_%Y-%m-%d-%H 3600 -0" > CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/www.mozilla.com/access_%Y-%m-%d-%H 3600 -0" urchin env=!is-forwarded > CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/www.mozilla.com/access_%Y-%m-%d-%H 3600 -0" x-forwarded-for env=is-forwarded > > AddDefaultCharset UTF-8 > AddType image/svg+xml .svg > AddType application/vnd.mozilla.xul+xml .xul > AddType text/xml .rdf > AddType image/x-icon .ico > AddType text/calendar .ics > # StarOffice documents > AddType application/vnd.stardivision.impress .sdd > AddType application/vnd.stardivision.writer .sdw > AddType application/vnd.stardivision.draw .sda > AddType application/vnd.stardivision.calc .sdc > </VirtualHost> This is broken on trunk too <http://www-trunk.stage.mozilla.com/de/m/alpha>. Can you also reproduce on your dev environment? I assume this is either a bug in prefetch.php or .htaccess.
The alpha page is new and just went up with this push. Previously we've had a beta page /m/beta
Indeed; I think it was expected that the locale fallback would Just Work, like it does elsewhere.
Checking out the code to see what I can do.
OK, so the issue is that http://www.mozilla.com/fr/m/alpha.html will take you where you want to go (namely http://www.mozilla.com/en-US/m/alpha.html) but just /alpha won't. Elsewhere in the site /alpha would take you to alpha.html so this is why the behavior is expected. I'll try and fix the interaction between these rules so it works as expected.
Assignee: jlazaro → nobody
Component: Server Operations → www.mozilla.com
Product: mozilla.org → Websites
QA Contact: mrz → www-mozilla-com
Assignee: nobody → laura
Status: NEW → ASSIGNED
Attachment #469895 - Flags: review?(lorchard)
Comment on attachment 469895 [details] [diff] [review] deal with edge case Having a little trouble with my checkout, but this looks like it'd do the trick
Attachment #469895 - Flags: review?(lorchard) → review+
Sending includes/prefetch.php Transmitting file data . Committed revision 73207.
Ok, I've got no idea how to push this. Reassigning to server-ops, hopefully someone over there knows :)
Assignee: laura → server-ops
Component: www.mozilla.com → Server Operations
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → mrz
Assignee: server-ops → aravind
I think this needs to be tagged to go into production, afaict production is tagged under http://svn.mozilla.org/projects/mozilla.com/tags/production
(In reply to comment #15) > I think this needs to be tagged to go into production, afaict production is > tagged under http://svn.mozilla.org/projects/mozilla.com/tags/production oh wait.. no-one said this was ready to be pushed to production, I was just being jumpy.. this being a blocker bug and all..
Reverted authstage... r70788 - Twig merge r70784 - oldest prod includes/prefetch.php probably
(In reply to comment #15) Cool, I deploy to stage and prod often for moco, so we should be all set (once we have a working authstage).
r73211 should be testable by 10:20.
Patch chose the wrong area of code. 3rd attempt r73214. On stage by 10:40.
Committed to prod after manually applying 3rd attempt patch r73215.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
@abuchanan - Sorry, expect conflicts when you merge trunk into stage (and later prod). Please see Comment#17 for details.
Works in prod.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: