Some websites break if you try to access https:// - from my experience of using Https Everywhere.
It's a simple fix to whitelist the one website though. It doesn't break the Internet. It breaks sometimes, for some users, and is trivially fixable when it does break.
"Fundamentally breaking the internet", to me, is something that actually breaks the usability of the internet in a non-trivial-to-fix way for the end user where the end user isn't even in control of the fix. That's breaking the web.
Failing to support IE5 is "breaking the web" in the same way Https Everywhere breaks the web. In a way that is to be fixed on the user-end.
(Although sites that fail to serve over https:// should fix their site)
There's probably a technical reason I'm unaware of, but why are you allowed to have HTTP and HTTPS handled differently (besides then encryption portion)?
HTTP and HTTPS use different ports (TCP 80 and 443). You can run one web server application on the HTTP port serving content A, and a completely different web server application on the HTTPS port serving content B. With firewalls doing NAT port translation this could even result in HTTP requests going to a completely different machine than the HTTPS requests.
From a non-tech reason, there are some types of sites that the HTTPS content should never be available on a HTTP site. For example an online payment form. In such cases a sensible website will either disable HTTP entirely (and use a subdomain for secure content, rather than the top leve/ www. domain), or have a basic HTTP site that transparently redirects to the HTTPS version.
Servers can really do whatever they want, based on whatever they want. They can serve a different page to clients based on e.g. "Accept-Language": "en" might be a completely different page than "fr", rather than just a translation.
That's just how it happened. And historically, it was common to put only the "important things" behind TLS. That never really made sense from a security perspective, but it certainly saved CPU cycles.
Yeah, but that's a subset of "misbehaving servers break the web" as far as I can tell. HTTPS doesn't inherently cause this problem, it just provides one theoretical nucleation point for it.
Protocol-less URLs are usually a bad idea. They mean "use http or https depending on whatever the current page is", but there are very few situations where that is a useful way of making that decision. What you should do is specify https in the link, unless you know that the target site doesn't support https, in which case of course you have to specify http.
Which is good. With TLS variant you would have to ensure that anyway for security reasons or you open doors to injection attacks. Mitigated by keep alive with pipelining and socket reuse, but there.
This works fine if you use anchors without protocols in your html:
a href="//site.com/resource"