rewrite issue with http://www.mozilla.org/download Accept-Language:zh-TW

RESOLVED FIXED

Status

Infrastructure & Operations
WebOps: Other
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: sancus, Unassigned)

Tracking

Details

(Reporter)

Description

5 years ago
We added a rewrite to deal with a case from Bug 764261. Intended functionality is that http://www.mozilla.org/download with Header Accept-Language: zh-TW gets redirected to http://mozilla.com.tw/firefox/download -- but the rewrite is not working at all, it seems to have no effect.

https://github.com/mozilla/bedrock/commit/622f5969d1914838e29812fb68a5c9dd2a693c28

Is the rewrite. The other rewrites in global.conf seem to be functioning, so I'm not sure why this one is failing, whether it has to do with the order of rewrites processed between the various servers that serve mozilla.org URLs, or something else. I can't reproduce the issue locally, the RewriteCond seems to work for me, but I don't have a duplicate of the production server chain.
:sancus - all the rewrites in production can be found at the following location in gitub:

  https://github.com/mozilla/bedrock/tree/master/etc/httpd


there is nothing extra we in webops manage in addition to these for our production web servces so am not entirely sure what i can do to help you sort this out. i wonder if the root cause is the %{HTTP:Accept-Language} header is not present in the cases that are failing?

Comment 2

5 years ago
Firstly, I don't see this rewrite deployed on prod.... is it not pushed there currently?

[jakemaul@jakebook ~]$ curl -v -H 'Accept-Language: zh-TW' http://www.mozilla.org/download
* About to connect() to www.mozilla.org port 80 (#0)
*   Trying 63.245.217.105... connected
* Connected to www.mozilla.org (63.245.217.105) port 80 (#0)
> GET /download HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: www.mozilla.org
> Accept: */*
> Accept-Language: zh-TW
> 
< HTTP/1.1 302 Found
< Server: Apache
< X-Backend-Server: bedrock1.webapp.phx1.mozilla.com
< Cache-Control: max-age=900
< Content-Type: text/html; charset=iso-8859-1
< Date: Mon, 28 Jan 2013 19:51:20 GMT
< Location: http://www.mozilla.org/projects/
< Expires: Mon, 28 Jan 2013 20:06:20 GMT
< X-Robots-Tag: noodp
< X-Cache-Info: caching
< Content-Length: 216


Makes me suspect there is some other rewrite/redirect that is (or may be, once it's deployed) superseding this one.
i just did a quick `git log` on the prod bedrock admin node and see the following:

[root@bedrockadm.private.phx1 bedrock]# git log -1
commit b7a01259848eaf06aef32521811ed1d2b2854c1b
Merge: eac1e01 15fca6b
Author: Paul McLanahan <paul@mclanahan.net>
Date:   Thu Jan 24 10:12:43 2013 -0800

    Merge pull request #609 from sgarrity/cleanup-firstrun
    
    Remove Fabook social-api promo from firstrun


i suspect :jakem is right. this rewrite rule update has not yet been pushed to the prod servers via chief.
(Reporter)

Comment 4

5 years ago
Sorry, I should have been clearer. The patch isn't on production yet, because it wasn't working on staging in testing, but it is on www-dev and staging and it doesn't work there either:

lwp-request -dSH 'Accept-Language: zh-TW' http://www.allizom.org/download
GET http://www.allizom.org/download --> 301 Moved Permanently
GET https://www.allizom.org/download --> 302 Found
GET http://www.mozilla.org/projects/ --> 301 MOVED PERMANENTLY
GET http://www.mozilla.org/zh-TW/projects/ --> 301 MOVED PERMANENTLY
GET http://www.mozilla.org/zh-TW/products/ --> 301 Moved Permanently
GET http://mozilla.com.tw/products/ --> 200 OK
(Reporter)

Comment 5

5 years ago
It appears that it's being superseded by the rewrites from the PHP .htaccess file(s) but I don't understand why because I was under the impression that the rewrites in https://github.com/mozilla/bedrock/tree/master/etc/httpd were processed before everything else. I am wrong about that?
(Reporter)

Comment 6

5 years ago
I added the exact same rewrite to the top of the .htaccess in svn.mozilla.org/projects/mozilla.com/trunk/ -- and now it seems to work:

[sancus@sancus trunk]$ lwp-request -dSH 'Accept-Language: zh-TW' https://www-dev.allizom.org/download
GET https://www-dev.allizom.org/download --> 301 Moved Permanently
GET http://mozilla.com.tw/firefox/download/ --> 200 OK

So.... I guess bedrock rewrites are not processed first? That's hard for me to believe, otherwise doesn't that mean all the /b/ rewrites are subject to being screwed up by the PHP code?
ping?

Comment 8

5 years ago
(In reply to Andrei Hajdukewycz [:sancus] from comment #6)
> So.... I guess bedrock rewrites are not processed first? That's hard for me
> to believe, otherwise doesn't that mean all the /b/ rewrites are subject to
> being screwed up by the PHP code?

This is correct (took some digging to verify). If you have a matching rewrite in .htaccess, that will "win" and the Include files will lose. There is no easy way around this.


However, this should be a non-issue... the PHP/.htaccess file should be responsible for items managed by PHP/SVN. The Include files in git should be responsible for content managed by Bedrock. Which section of code handles /download? It can't be both. Right now it appears to be just a redirect, handled in PHP.

Whichever side is responsible for that page should contain both this Accept-Language rewrite *as well as* the default download->projects redirect. That means this new redirect should go in the .htaccess file, *or* both redirects should be in the global.conf file.
(Reporter)

Comment 9

5 years ago
OK. Thanks for the information, that's helpful. Regarding this specific issue, I'm just going to move the rewrite to the php .htaccess file and leave it at that. We'll need to Seriously Tackle Rewrites eventually, but today is not that day.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(In reply to Andrei Hajdukewycz [:sancus] from comment #9)
> OK. Thanks for the information, that's helpful. Regarding this specific
> issue, I'm just going to move the rewrite to the php .htaccess file and
> leave it at that. We'll need to Seriously Tackle Rewrites eventually, but
> today is not that day.

Completely agree. Thanks!
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.