<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 02/15/2015 08:25 AM, <a class="moz-txt-link-abbreviated" href="mailto:sjw@gmx.ch">sjw@gmx.ch</a> wrote:<br>
<span style="white-space: pre;">> But the browser ties to
reconnect using '<a class="moz-txt-link-abbreviated" href="http://www.host.TLD">www.host.TLD</a>'. Should we let<br>
> the browser do this redirect itself (and redirect again to
https) or<br>
> should we overwrite this redirect and directly connect to
'<a class="moz-txt-link-freetext" href="https://www">https://www</a>.'?</span><br>
If a target host doesn't answer on port 80, or the name doesn't
exist, we shouldn't include it in the ruleset. We don't expect that
there will be links on the web to the nonexistent host, so we don't
lose much in terms of ability to rewrite URLs.<br>
<span style="white-space: pre;">> Another problem that I found
are incomplete certificate chains. The<br>
> browser correct them with an extra download, but<br>
> https-everywhere-checker returns: 60, 'SSL certificate
problem: unable<br>
> to get local issuer certificate'<br>
><br>
> This should return a warning instead of an error.</span><br>
Good point! I think we are also missing some of the most current
certificates from Firefox, which I plan to update:
<a class="moz-txt-link-freetext" href="https://support.google.com/dfp_sb/answer/2524536?hl=en">https://support.google.com/dfp_sb/answer/2524536?hl=en</a>. If we still
have issues after updating those, we may want to install the
transitive closure of those certificates, from the SSL Observatory.<br>
<br>
</body>
</html>