Closed Bug 697243 Opened 13 years ago Closed 9 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: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.