5 ms·
It only breaks the web if you cut everything over from http to https. If you can serve both you don't have a problem. This works fine if you use anchors withou
by dcw303 10y ago
It only breaks the web if you cut everything over from http to https. If you can serve both you don't have a problem.
This works fine if you use anchors without protocols in your html:
a href="//site.com/resource"
- Nadya 10y agoSome websites break if you try to access https:// 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:// https:// should fix their site)
- colejohnson66 10y agoThere'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)?
- zAy0LfpBZLC8mAC 10y agoThat'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.
- c3833174 10y agoI don't really like when I'm not able to read the news because HTTPS didn't want to collaborate with an unreliable connection.
- CydeWeys 10y agoBecause no one ever prohibited it (ignoring issues of whether that is a good idea), and it's way too late to change it now.
- jessaustin 10y agoServers 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.
- yardstick 10y agoTechnical reason: Multiple ports = multiple apps. 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.
- RubyPinch 10y agoI think its safe to say "it breaks the web" is from the user perspective, not the server. It only takes 1 server to serve differing content through each protocol to break things for the user
- seandougall 10y agoYeah, 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.
- cbr 10y agoServing different things on https and http is completely to spec, though. It's not really a server misbehaving. (I do agree that it's contrary to expectations, but I'm sure this doesn't stop sites from relying on it.)
- anewhnaccount 10y agoProtocol-less urls use the same protocol as the current page. This resolves nothing.
- AstralStorm 10y agoWhich 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.
- anewhnaccount 10y agoIt has nothing to do with the points made in TFA.
- voyou 10y agoProtocol-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.