Closed Bug 1357563 Opened 8 years ago Closed 8 years ago

[Kitsune Rollback] Correct the URL Structure for any Lithium links we miss

Categories

(Firefox :: General, enhancement)

Product:
Firefox
Component:
General
Version:
54 Branch
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: elan, Unassigned)

References

Details

We will know if this is actually happens after 7AM tomorrow, I just want to give us a meta bug to put any breakage in.
Depends on: 1357606
Hope this is not bug spam or premature but I note the in-product link from: Firefox (Desktop) > Menu > Help > Firefox help is 404 for me at present. It tries to open https://support.mozilla.org/en-US/t5/Firefox/ct-p/Firefox
:John99 this is a good catch. No such thing as spam right now. Team is actively investigating, I will ping you once we have a fix. Thank you so much for reporting!
(In reply to John Hesling [:John99] (NeedInfo me) from comment #1) > Hope this is not bug spam or premature but I note the in-product link from: > Firefox (Desktop) > Menu > Help > Firefox help > is 404 for me at present. > > It tries to open https://support.mozilla.org/en-US/t5/Firefox/ct-p/Firefox i can't reproduce this in Firefox 53, Windows 10, German Build It correctly opens: https://support.mozilla.org/de/products/firefox Firefox 55 nightly, Mac OS X 10.11, English build correctly opens https://support.mozilla.org/en-US/products/firefox What am I missing :John99?
Testing locally and using a plugin to stop the quick redirect. The help link goes to https://support.mozilla.org/1/firefox/52.0.2/Darwin/en-US/firefox-help It looks like the browser is caching the redirect to lithium. If I go to that url directly it goes to the correct kitsune link. I think this is a temp issue caused by caching.
OK more info on this one... That help link, for users that went to it while lithium was live.. they will have a URL/redirect cached by the browser. The bad news is that the cache is set for 31536000 seconds. Looking into this further....
The problem is the Lithium has been issuing "301 - Permanent Redirect" for its redirects and if a browser has visited Lithium in the past it has this cached. New installations don't face this and that probably explains why some of you see this and some don't. Analysis 1. /1/firefox/52.0.2/Darwin/en-US/firefox-help - Kitsune 302 redirects to https://support.mozilla.org/en-US/products/firefox?as=u&utm_source=inproduct cmd to test it out: curl -H "Host: support.mozilla.org" https://support.mozilla.org/1/firefox/52.0.2/Darwin/en-US/firefox-help -I - Lithium 301 redirects to http://support.mozilla.org/products/firefox cmd to test it out: curl -H "Host: support.mozilla.org" secure02.lithium.com.edgekey.net/1/firefox/52.0.2/Darwin/en-US/firefox-help -I So despite the 301 reply the IPR points to the correct URL in both cases. The problem lies deeper: 2. /products/firefox/ - Kitsune 302 redirects to https://support.mozilla.org/en-US/products/firefox/ cmd to test it out: curl -H "Host: support.mozilla.org" https://support.mozilla.org/products/firefox/ -I - Lithium 301 redirects to http://support.mozilla.org/t5/Firefox/ct-p/Firefox cmd to test it out: curl -H "Host: support.mozilla.org" secure02.lithium.com.edgekey.net/products/firefox -I This means that the cached redirect that causes the issue is https://support.mozilla.org/products/firefox and not the in product link. It should also affect users who just go to /products/firefox if they have visited Lithium anytime in the past. The 301 redirects Lithium issues are permanent and stored in the browser indefinitely as the cache size permits or until cache gets cleared.
:John99, here is information about how to clear your browser cache. You probably are well aware but just in case: https://support.mozilla.org/en-US/kb/how-clear-firefox-cache.
I have tested it z few times,it is now working as expected.
Flags: needinfo?(John99-bugs)
John - correct resetting cache does work. Unfortunately that's a manual step and I do not think most users will do that. A bit more info. This only impacts users who visited specific redirected pages while lithium was live. Users who upgrade FF, they get a new version number in the URL, so that breaks cache on those in product urls (good). It is still not ideal. I am poking around to see if I can get a concrete sense of actual impact on users and a rec on what we should do next.
Summary: [Kitsune Rollback] Correct the URL Structure for Any Lithium Links We miss → [Kitsune Rollback] Correct the URL Structure for any Lithium links we miss
Yes I can get this to open both the 404 and the correct page in adjacent tabs in the same browser instance by using containers. We do have an announcement on the 404 page about using IRC for help, the need to re register, and the re posting of posts. Clearly we are expecting Lithium users may come back again to follow up on an ongoing or new question. The announcement is: > IMPORTANT ANNOUNCEMENT: We’re going through some changes. If you had asked a question in the last couple of months, please re-post it and the community will help you. >If you’ve registered after February 7th, please register again, as the accounts on the previous site are not on this temporary site. If you joined us before February 7, please reset your password if you have trouble logging into the site, we have help on standby in https://kiwiirc.com/client/irc.mozilla.org/sumo. Even on that 404 page the dropdown menus work so any signed in user that gets that far can use the standard workflow to ask a question. Possibly more important is users trying to follow prior questions using bookmarks History or Email subscriptions those are going to be 404 (Anyone in this thread want to comment on a bug I filed about email notifications: bug 1352806 ) Another issue is that we did have RSS subscriptions and those of course are not going to load, but I imagine that is a bit of an edge case.
John, thanks for mentioning some of the additional circumstances where the 404s can pop up. Giorgos and I are noodling with something to handle the cached redirects from lithium. More research required on that one but hopefully we can sort out tomorrow. The above likely won't directly address the issue with Lithium questions that do not exist on kitsune. However it may be possible we can redirect anything with a lithium looking url (contains /t5/) to a page that explains the situation and what they should do. Oh yeah and we will get lithium to switch to 302 redirects not 301 that never expire! For the email notification bug.. I'll needinfo patrick on that one to file a support case with lithium. That one should wait until we are stable again.
Added bug 1357950 to specifically track the Lithium content.
John if possible, can you try this again and see if it is fixed. I both updated my browser yesterday and cleared my cache so I can no longer reproduce. Giorgos implemented a solution that should solve the cached redirect issue and I would love to verify its fixed so we can close this out. Much thanks.
Flags: needinfo?(John99-bugs)
Ben yes it appears to be fixed. I had cleared the cache for an unrelated reason, but had another profile where I had clearly used Sumo Lithium, because it even opened with Sumo 404 tabs. I tried the in product help option and it opened ok. It opened to https://support.mozilla.org/en-US/products/firefox?as=u&utm_source=inproduct That was testing on fx52.0.2 that had clearly not yet updated. I did by the way see a similar issue on Firefox Android earlier on, but will have probably cleared all the caches so I don't think I could test those now.
Flags: needinfo?(John99-bugs)
Excellent, thanks for checking and for now this is good enough for me to call this one resolved. I will wait a bit before closing out this bug but it looks like we have a fix for the long lived redirect.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Commit pushed to master at https://github.com/mozilla/kitsune https://github.com/mozilla/kitsune/commit/386c05b3402b7daf1438655bc0d66606bdf272ec [bug 1357563] Remove checks from Lithium website. (#2913) Lithium shut down our instance, we cannot check page titles anymore.
You need to log in before you can comment on or make changes to this bug.