Infinite redir reported by search console

An example link is:

https://addons.mozilla.org/en-US/firefox/addon/leechblock/%0A

This only causes an infinite redir on the react-based site.

For QA: the URL above should not crash. In -dev or -stage, you can try with any add-on detail page URL with /%0A at the end, example:

• https://addons-dev.allizom.org/en-US/firefox/addon/foxyproxy-standard/

[bqbn]

Although I’m not sure why the frontend is returning 404s now when it was issuing a redirect in the past.

That’s because previously, /en-US/firefox/addon/foxyproxy-standard/%0A is matched and routed to the frontend. The frontend then 301 the request to /en-US/firefox/addon/foxyproxy-standard/%0A/. The second URL is then matched and routed to the legacy site, which 301 to the first URL, thus causing a loop.

Now that everything is routed to the frontend by default, the above second URL is no longer routed to the legacy site, thus the frontend is able to get it and return 404.

What’s interesting is that when Nginx gets a URL like /en-US/firefox/addon/foxyproxy-standard/%0A, the effective part it uses to do location match is just /en-US/firefox/addon/foxyproxy-standard/, and that’s why the request got routed to the frontend when it shouldn’t in our case (we had a rule to match just /<locale>/<app>/addon/<slug>/). What’s worse is that Nginx still sends the whole URL string to the upstream even though it only used a part of it to do the match.

[autrilla]

Sounds good to me as well. Although I’m not sure why the frontend is returning 404s now when it was issuing a redirect in the past.