https:// https:// is a scheme, not a protocol. In retrospect, it probably should have been called "www://" and "wwws://" rather than http:// http:// and https:/

https:// https:// is a scheme, not a protocol. In retrospect, it probably should have been called "www://" and "wwws://" rather than http:// http:// and https:// https://, because a single scheme can potentially be resolved via several different protocols. Consider that http:// http:// does not necessarily imply unencrypted access, due to the opportunistic encryption specification (though this encryption is not MitM-secure). Also note that because http:// http:// and https:// https:// are different schemes, there is no requirement that they serve the same website. http://example.com/foo http://example.com/foo and https://example.com/foo https://example.com/foo could be completely different resources, or completely different websites. An opportunistically encrypted load of an http:// http:// URL still needs to load the http:// http:// website, not the https:// https:// one. Though opting in to HSTS eliminates this distinction. For that matter, HTTP/1.1 allows full URLs to be specified in the request line, as an alternative to the traditional "Host" header. This is usually only used when using HTTP proxies: GET https://example.com/foo HTTP/1.1 ... but what is interesting is since this also includes the scheme, it potentially allows you to do something very peculiar: theoretically you could access an https:// https:// logical resource over an unencrypted HTTP/1.1 connection, e.g. by telnetting to example.com:80 and issuing "GET https://example.com/foo https://example.com/foo HTTP/1.1". It would of course be insane to support this, but if one disregards the fact that https:// https:// is supposed to invariably imply secure communication, theoretically even https:// https:// resources could be loaded unencrypted, just as http:// http:// resources can be loaded encrypted using opportunistic encryption. In short: scheme and protocol are different things, and for good reason. URIs are resource identifiers. They exist to identify a resource, not how to access it. Tying those resource identifiers to a means of resolution would unnecessarily couple it to a resolution mechanism and thereby reduce the universality and permanence of URIs. URIs which are URLs are closer to describing a means of access but fundamentally there's still an interest in providing enough degrees of indirection that the longevity and permanence of an URL is maximised.