3 ms·
Maybe they shouldn't have used http:// http:// for something that isn't http. Nah, users are too dumb and "my precious adoption rates"
by aaronax 3y ago
Maybe they shouldn't have used http:// http:// for something that isn't http.
Nah, users are too dumb and "my precious adoption rates"
- xg15 3y agoI guess it's more "my precious marketing". General consensus in marketing seems to be that people can't memorize anything more than domain names, and maybe also a "www." or a single word path behind the domain - but the scheme seems to be universally seen as "technical cruft that non-technical users can't be expected to deal with". (with the one exception that "http:// http:// = bad and https:// https:// = good") So I guess companies don't want a situations in which they suddenly have to teach their users that, no, it's not "awesomecorp.com", it's actually "https3://awesomecorp.com" (but NOT https://3awesomecorp.com https://3awesomecorp.com, that's a scammer) etc etc
- ekr____ 3y agoThe main motivation here is the desire to have a seamless transition to newer protocols without having to change the site. This way, your hosting service can enable HTTP/3 and it will just work with an HTTP/3 compatible browser. This is the way every upgrade in TLS and HTTP has worked for quite some time. It's especially important with HTTP/3 because there are network environments where HTTP/3 doesn't work and so you need to fall back to HTTP/2, and you obviously want that to work seamlessly. In addition, the basic security structure in the Web is the origin, defined in RFC 6454, and origins are defined by a triplet of [scheme, host, port]. It would not be good to have HTTP over TLS and HTTP/3 be different origins. For instance, you don't want to lose all your cookies if the site turns HTTP/3 on or off.