[geocar]

> I still never use 301s for that reason. Things may have changed, but I dare not try!

I use 301 for http:->https: redirects because (a) I doubt we're going back, (b) it prevents some cleartext leaks (like the Host header), and (c) it is slightly cheaper.

> we never figured out how to get the browser to re-learn the responses for those pages without drastic measures.

If you control the target URL it is easy, just redirect back. Seriously: The browser won't loop, it'll just fetch the content again and now not seeing a 301 will forget that nonsense ever happened. This is why 301 is usually a fine default for same-site redirects, or if the redirect target is encoded in the URL (such as in tracking URLs).

The big no-no is don't 301 to a URL you can't control unless you have the appropriate Cache-Control headers on the redirect.

[throwawaymobule]

Isn't there a https upgrade header specifically for this kind of thing?

[geocar]

Not to my knowledge. How exactly do you think it works?

[moehm]

426 Upgrade Required

[swiftcoder]

> If you control the target URL it is easy, just redirect back. Seriously: The browser won't loop

Just uh... don't do this if you have a CDN infront of your site. We had an incident where Cloudfront cached the 301's in both directions

[geocar]

Yeah that's a good point, but one way to think about a CDN is like a web browser that you control, so I say do it even with a CDN and remember you can always just flush the "browser" cache! (or in cloudfront's case: create an invalidation and wait a few seconds)