Https-everywhere: Strict: Attempt to open page on refreshing the warning page.

[jtagcat]

Type: feature request
So I got rightfully blocked:

The cert expired. I renewed it and made cron do it next time.

Expected:
Press F5 and the now renewed site is accessed fine.

This behaviour is taught to users by say HTTP responses 408. 418, 426, 500, 502 or 503: refreshing the page magically works.

Current:
Press F5 and the same page appears. Opening the site in a new tab _now_ works fine.

[zoracon]

From what it sounds like, the request probably held some old information temporarily and it took some time to repopulate the updated information. Is it still doing this after that initial refresh issue. Like in a new browser session?

[jtagcat]

Why should it be in a new browser session?

User opens: k-space.ee
EASE blocks http connection
https is now available
User can open k-space.ee in a new tab fine.
Refreshing the EASE page should result in the page displayed as well.

[zoracon]

What I meant was: as you were updating your cert, did you keep the initial block page open during this time, then refresh the block page during this time frame?

As of right now, navigating to http://k-space.ee redirects me to https://k-space.ee.

[jtagcat]

Yes, the page was kept open (as a new page delivered to https://k-space.ee successfully).

[zoracon]

So my guess is the EASE page that you kept open was holding on to the details of the request before the cert was updated. Admittedly that is not an ideal network flow for EASE and we can try to make it smarter by releasing the previous network details and get the new ones.

[zoracon]

Closing for now, since this is a case where the cert was renewed while the EASE mode page was opened and considering it takes time for an update for an to HTTPS to populate within browsers generally I am not able to isolate this issue just to EASE.