More information about the Underscore mailing list

[_] https://www

Oliver Kohll oliver at agilechilli.com
Mon Apr 15 22:51:49 BST 2019

Dear _,

In our software, we detect URLs that people may type in (e.g. a web address, twitter or LinkedIn URL into an organisation record in a database).

If someone types www.domain.co.uk, we automatically prepend https:// when turning it into a link, or when a routine on the server queries it, e.g. to extract an icon/image from it.

My assumption was that this would work pretty much all the time but from reports, it seems to fail quite often resulting in a certificate error like e.g. "NET::ERR_CERT_AUTHORITY_INVALID" from Chrome.

For many URLs, including some for the companies of subscribers to this list, what you type into the browser and the results are

https://domain.co.uk -> view website normally
www.domain.co.uk -> redirected to https://domain.com
http://www.domain.co.uk -> redirected to https://domain.co.uk
https://www.domain.co.uk -> failure

I've been assuming as HTTPS becomes ubiquitous, this type of configuration (oversight?) will decrease but thinking about it, there also seems to be a trend towards deprecating the use of www. in domains which does indeed seem to be rather unnecessary as a prefix so maybe people aren't bothering.

I guess the options are
1) don't prepend anything. I'm not sure how serverside HTTP clients would react but could try it out (after trying, the Apache Java HTTP client at least doesn't like it)
2) prepend http:// - doesn't seem right but I guess that's what browsers are effectively doing
3) prepend https:// assume websites are gradually going to address things

I'm leaning towards 2, treating http as the default and letting the redirect to https which most sites should have work. If it's good enough for Google Chrome etc...

Would anyone do anything different?

Oliver
www.agilechilli.com