+++ This bug was initially created as a clone of Bug #840687 +++ +++ This bug was initially created as a clone of Bug #771788 +++ app.support.baseURL;http://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/ Should become https:// at some point. (In reply to James Socol [:jsocol, :james] from comment #2) > (In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment > #1) > > These bugs are probably best filed per-host. support.mozilla.org link > > changes require sign-off from different people than mozilla.com links. I > > think mozilla.com/org can probably just be changed wholesale. > > support.mozilla.org in particular is not really designed to have all traffic > come over HTTPS right now. I don't think it would cause the site to fall > over, but there are changes we would really rather make before Firefox > changed to HTTPS-only. That sounds fine to me. I filed these bugs as part of triaging bugs with "HTTPS" in the summary from Firefox:Untriaged. I don't have a strong opinion on the prioritization of this bug, in particular.

Redirect map https://support.mozilla.org/1/firefox/19.0/Darwin/en-US/ -> https://support.mozilla.org/en-US/products/firefox?as=u&utm_source=inproduct

James, are there SUMO/Ops bugs tracking what needs fixing before we can make this in-product switch?

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #2) > James, are there SUMO/Ops bugs tracking what needs fixing before we can make > this in-product switch? I just filed bug 848520, but unless this is a high priority for Firefox I'm not sure it can be a terribly high priority for SUMO at this point in the quarter.

Comment on attachment 721620 [details] [diff] [review] v1 We'll need to wait on the blocking bugs before landing this.

Gavin, can you comment on the priority of this? It looks like this might be a major undertaking for us.

I don't think this is high priority; it would nice to have. One question, though: bug 848520 seems to be tracking "all SUMO traffic over https". That seems like a superset of what's required for this bug. For this bug, we just need SUMO to not fall over when we change the in-product links to the (already-working) https versions. Does that really involve a lot of work on the SUMO side? Do you have data for what percentage of your visits come from the in-product links?

Kadir, can you answer comment 6?

Yeah, in-product links make up 42% of our visits.

So just to be clear, that's a "yes, supporting https for 42% of visits requires a significant amount of preperatory SUMO work"?

Yes, we need to do preparatory SUMO work.

We are all set from the SUMO side here. We've been redirecting all the in-product links to https for a few weeks now and haven't had any issues.

Awesome - thanks!

Verified fixed on Windows 7 64bit, Ubuntu 13.10 and Mac OSX 10.8.5 using latest Nightly 34.0a1.