I just made this blog HTTP and HTTPS, thanks to Cloudflare.
But that made me realize that lots and lots of internal links in the HTML output of my WordPress point back to the HTTP version of the site.
Part of the solution to this is to install the HTTP plugin in WordPress which fixes some of the mess. But some of the URLs in my posts need to be fixed too.
The best practice for links inside of a website to “inherit” the context where they are eventually found by keeping them as relative as possible. Thus it’s better to use “/tags/geeking” than “http://blog.nella.org/tags/geeking”, because if you want a test and production version, or you rename the blog, or whatever, you’ll be happier later if the links are not absolute when they are first typed.
And if you want your website to adapt to having both an HTTP and an HTTPS version, you really want relative links because that means that the web browser will choose the correct scheme, keeping HTTPS sessions inside the HTTPS version of the website.
But what if you want to refer to an off-site resource? And that resource exists in both HTTP and HTTPS versions? Then you need to give a hostname and path (because it is no longer relative to your hostname), but not a scheme (so that the scheme is relative to the context where the relative URL is found).
Such beasts exist. They look weird, but they exist and are handled correctly by modern browsers (I guess there’s some old browsers that chow on them). They look like “//hostname.domain.com/path/path/file.html”. That says, “if you found this on an HTTP page, go get it from hostname port 80. If you found this on an HTTPS page, go get it from hostname port 443.” Whee!
Which reminds me of the HP Apollo lab in Harvey Mudd (where I was working on NeXT and Ultrix machines, not HP ones, thankfully). And it also reminds me of a taxi ride to a conference center in San Jose where the guy who invented the HP network filesystem syntax told me that his invention of //host/path accidentally ended up inside of HTTP URL’s.
Leave a Reply