"en/" in a document slug triggers a redirects to "/en-US/"

NEW
Unassigned

Status

6 years ago
2 years ago

People

(Reporter: sheppy, Unassigned)

Tracking

Details

(Reporter)

Description

6 years ago
When someone puts "en/" in a locale, weird things happen. You get a page that directs you to the en-US/ locale for that page, instead of loading the page itself. Or something. See https://developer.mozilla.org/fr/docs/en/Using_files_from_web_applications for example.
This is due to legacy MindTouch URL redirection handling, found here:

https://github.com/mozilla/kuma/blob/master/apps/wiki/models.py#L1200

So, any wiki path that looks like "/{locale1}/docs/{locale2}/blah/blah" will get redirected to "/{locale2}/docs/blah/blah". 

That means any document that really has a recognized locale in its path will be inaccessible. We need some way to disable this redirection, maybe with a ?redirect=no parameter
Summary: When "en/" is used in a slug, things get weird → "en/" in a document slug triggers a redirects to "/en-US/"
(Reporter)

Comment 2

5 years ago
I wonder how common this is.

Comment 3

5 years ago
We might be able to get an idea using Google analytics?
Flags: needinfo?(lcrouch)
tl;dr ~ 0.07% of requests are like this.

Hmm ... not in Google Analytics, no. GA requires a pageview to track, and 301 responses make the browser change locations before running any JS.

I didn't see this in New Relic either. We might get this data from New Relic when we upgrade our agent.

I even checked our old Graphite dashboard, but it's broken.

So, I grep'd the apache logs and came up with 85/113,004 = 0.07% of requests like this. Work shown here for extra credit:

[lcrouch@developer1.webapp.scl3 kuma]$ grep -rEn "/\w+/docs/en/" /var/log/httpd/developer.mozilla.org/access_2014-03-20-17 /var/log/httpd/developer.mozilla.org/access_2014-03-20-18 /var/log/httpd/developer.mozilla.org/access_2014-03-20-19 /var/log/httpd/developer.mozilla.org/access_2014-03-20-20 /var/log/httpd/developer.mozilla.org/access_2014-03-20-21 /var/log/httpd/developer.mozilla.org/access_2014-03-20-22 | wc -l
85

[lcrouch@developer1.webapp.scl3 kuma]$ wc -l /var/log/httpd/developer.mozilla.org/access_2014-03-20-17 /var/log/httpd/developer.mozilla.org/access_2014-03-20-18 /var/log/httpd/developer.mozilla.org/access_2014-03-20-19 /var/log/httpd/developer.mozilla.org/access_2014-03-20-20 /var/log/httpd/developer.mozilla.org/access_2014-03-20-21 /var/log/httpd/developer.mozilla.org/access_2014-03-20-22
   19585 /var/log/httpd/developer.mozilla.org/access_2014-03-20-17
   19133 /var/log/httpd/developer.mozilla.org/access_2014-03-20-18
   17764 /var/log/httpd/developer.mozilla.org/access_2014-03-20-19
   26141 /var/log/httpd/developer.mozilla.org/access_2014-03-20-20
   26751 /var/log/httpd/developer.mozilla.org/access_2014-03-20-21
    3630 /var/log/httpd/developer.mozilla.org/access_2014-03-20-22
  113004 total
Flags: needinfo?(lcrouch)
(In reply to Luke Crouch [:groovecoder] from comment #4)

> [lcrouch@developer1.webapp.scl3 kuma]$ grep -rEn "/\w+/docs/en/"

I think this grep misses the problematic cases for this bug. The issue isn't /docs/en, it's more like /fr/docs/foo/bar/en/baz/quux - the /en/ shows up somewhere in the middle and I think it triggers the redirect logic.
See Also: → bug 1245858
You need to log in before you can comment on or make changes to this bug.