3 ms·
Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later
by devrandomguy 9y ago
Looking at the ID format in the first example, I have to recommend against including the protocol ("https:") in a key/ID. This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. It also makes it hard to try out new protocols side by side, like IPFS.
- blowski 9y agoA URL always includes the scheme. `http://www.example.com/1/ http://www.example.com/1/ ` and `https://www.example.com/1/` https://www.example.com/1/` could represent different content. If you want to change the scheme but keep the old links working, you need to redirect from the old to the new.
- Filligree 9y agoThat is the definition of a URL, but not a law of nature. If these keys would be more useful with the scheme being implicit, then perhaps they shouldn't be URLs.
- cat199 9y ago> This makes it hard for people to later upgrade from HTTP to HTTPS, because it breaks all of those references. While someone else pointed out the rest of the URL could conceivably point to different content, in practice, it seems like most deployments have a 1:1 correspondence and will redirect from http:// http://(.) to https:// https://(.) when SSL is deployed so this is not so critical for the http(s) case imho..