Closed Bug 697243 Opened 13 years ago Closed 8 years ago

Remove unused locale subdomain Rewrite Rule

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: nmaul, Unassigned)

References

(Blocks 1 open bug)

Details

In the .htaccess file for www.mozilla.org (in the main base, which is the old .com tree), there is the following RewriteCond/RewriteRule block.

# Handle file paths off the root, and add the locale back into the path
# based on the server name and/or domain.
# Examples:
#    http://{locale}.www.mozilla.com/firefox/central/ ->
#    http://{locale}.www.mozilla.com/{locale}/firefox/central/
RewriteCond %{SERVER_NAME} !^www\..*
RewriteCond %{SERVER_NAME} ^(\w{2,3})(-\w{2}(-mac)?)?\..*
RewriteCond %{REQUEST_URI} !^/(\w{2,3}(-\w{2}(-mac)?)?)(/.*)?$
RewriteCond %{SCRIPT_FILENAME} !^.*(php|css|js|jpg|gif|png|ico|pdf|swf)
RewriteRule ^(.*)$ /%1${toupper:%2}/$1 [R=permanent,L]


This is ostensibly designed to properly redirect subdomains containing the locale to their proper path. The problem is that it matches some requests which it shouldn't.

Specifically, it assumes any 3-character subdomain  that isn't "www." must be a locale. This assumption broke recently when a CDN was using the subdomain as a *location* tag (sjc.mozilla.com, phx.mozilla.com, etc).



As I understand it this was never actually used in production. It certainly isn't in use now, so at most this is legacy functionality.

In fact, I believe this may not actually even be reachable as intended: A request for "en-us.www.mozilla.com" results in an immediate 301 redirect to http://www.mozilla.org/firefox/, which is *not* what this block is trying to do. So, this block doesn't actually trigger when it's intended to.


Would you be willing/able to remove this altogether?
Target Milestone: --- → 4.4
If I remember well, this was to deal with hardcoded urls in older versions of Firefox (2.0 I think) which had urls hardcoded in the product in the form ab-CD.www.mozilla.com/ab-CD/path/to/page

I would be glad to have this hack removed though :)
James, Steven, Rik - Thoughts here? Can one of you take a look?
(In reply to Laura Forrest from comment #2)
> James, Steven, Rik - Thoughts here? Can one of you take a look?

I don't know of any uses of the ab-cd.* URLs that are still in use.
Yeah, I'm all for this. Scheduled for next week.
Assignee: nobody → jlong
Target Milestone: 4.4 → 4.5
Target Milestone: 4.5 → 4.6
There is also some code in include/prefetch.php, line 53:

if ($lang == null) {
    // We're hoping they went to a specific host like en-us.mozilla.org.  list() will
    // give us the first chunk.
    list($lang) = explode('.',$_SERVER['SERVER_NAME']);

    // If it's in our language array, we've got content, we're good to go.
    if (!in_array($lang, array_map('strtolower', $full_languages))) {
        $lang = null;
    }
}
Target Milestone: 4.6 → 4.7
Target Milestone: 4.7 → 4.8
Target Milestone: 4.8 → 4.9
Target Milestone: 4.9 → 4.10
Target Milestone: 4.10 → Future
Unassigning bugs from James that are not migration-related bedrock platform bugs. Let me know if you have any questions.
Assignee: jlong → nobody
Component: www.mozilla.org/firefox → www.mozilla.org
Rik, James, was this ever implemented? If not, is it still valid or can we resolve?
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
.htaccess is gone from www.mozilla.org.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.