848520 - [tracker] Make all traffic HTTPS

Status: RESOLVED FIXED

(support.mozilla.org :: General, defect, P3)

Description

[James Socol [:jsocol, :james]]

The Firefox team would like to switch to all-HTTPS for in-product links, which includes changing links to support. (See bug 841218 and anything it blocks.)

Right now, our caching strategy is very different for HTTP vs HTTPS traffic--we don't cache anything on the latter.

This bug is to track any changes necessary before all SUMO traffic can be over HTTPS. If it's just one thing, we can transform this from a tracker to an implementation bug.

Comment 1

[Kadir Topal [:atopal]]

Ricky, do we need to research this? If yes, we should put that into the 6th sprint. Putting it into it tentatively.

Comment 2

[Ricky Rosario [:rrosario, :r1cky]]

Sorry, I meant to ask James what his thoughts were here.

Is this about changing our caching strategy to cache some https traffic? Or is this about seeing if we even need to do that?

Comment 3

[James Socol [:jsocol, :james]]

IIRC, our caching strategy on HTTPS is never allow HTML to be cached. That may or may not be fine, load-wise, but it may not be a great experience, especially from Brazil.

So, I guess two questions:
1) Is cache-nothing OK for load? Can we still handle a pacman-level traffic surge?
2) Is cache-nothing OK for UX?

If either of those is "no," we need to look at a more nuanced strategy than just cache-nothing.

Comment 4

[Ricky Rosario [:rrosario, :r1cky]]

If we had to cache some HTTPS traffic, I think we could cache all responses from requests without one of the following cookies: SUMO_ANONID, anoncsrf or sessionid. And the responses cached can't have a Set-cookie in them, obviously.

Is that even doable?

Comment 5

[Ricky Rosario [:rrosario, :r1cky]]

I wanted to get Zeus caching (hit/miss) data but apparently that's not going to happen.

Random idea:
Add a waffle flag to switch inproduct redirects to HTTPS. We can start low at 1% or whatever and dial it up slowly keeping an eye on our load and performance graphs. If we are lucky, we will get to 100% without a sweat and we can then switch the actual inproduct links to HTTPS and remove the waffling code. If we find we can't handle the load, we'll come up with a plan so that we can.

Comment 6

[Kadir Topal [:atopal]]

This sounds good to me. Just one question: Browsers are caching HTTPS content these days, right? Just want to make sure they don't have to load all resources every time they navigate to another page.

Comment 7

[James Socol [:jsocol, :james]]

(In reply to Kadir Topal [:atopal] from comment #6)
> Just one question: Browsers are caching HTTPS
> content these days, right?

Quick testing (with our shiny new Network panel) shows that Firefox, at least, obeys cache control headers over HTTPS.

When I say we "don't cache anything" I mean rendered HTML. We still send long-lived cache headers for static files. Firefox is obeying these headers when we do send them.

Comment 8

[Kadir Topal [:atopal]]

Thanks for testing. Then I'm okay with whenever we want to start the test. Ricky, feel free to add to spring as soon you feel confident we can do this.

Comment 9

[Ricky Rosario [:rrosario, :r1cky]]

Q1 is in the past. Moving to the future.

Comment 10

[Ricky Rosario [:rrosario, :r1cky]]

I've been redirecting all inproduct traffic to https for a few weeks now and no issues. We should be all set to make the switch.