Enforced HTTPS - coming to a browser near you

give them a piece of my mind

Even a very small piece would be better than anything they’ve got…

I ought to find the idiot that did that code

A recent trend is to create a bit.ly shortened URL, then put that in the HTML code for a link that says something like “Your wanted file set here”
The fact that the code behind the visible link could be as long and complicated as they want seems to have escaped them.

Even more recently, a “bit.ly link”¹ to another link shortener² link to the real file, because it seems the message had got back that most places block bit.ly

¹ The visible text said “Bit.ly link” but was actually a different link shortener URL. I swear, the pet hamster we had was smarter than these people.

if you have web pages, and you want them to be accessible to MS Edge/Chrome/Firefox users, it’s time to review them and look at configuring them appropriately.

Should probably have addressed the issue when HTTP deprecation was announced in 2014, not leave it to the last minute!

I may have missed the point completely (as often), but isn’t !ConvText a handy tool for such replaces? Type http[58]//:https:// as a single script line and drag the root directory of your webpages to the iconbar icon. ConvText will then process every file in every subdirectory recursively.

when HTTP deprecation was announced in 2014

While my site has supported HTTPS for quite a while now, if you access the blog using a specific date via plain HTTP, it will not upgrade you.

I invite you to look at this to find out why I chose such behaviour:
https://heyrick.eu/blog/index.php?diary=20160928

Rick, that blog entry was 8 years ago. Do you think the same considerations still apply today?

I notice that it told me the IPv6 address that I accessed it from, and I recognise my /64 prefix. That’s progress!

Do you think the same considerations still apply today?

Given the context, it wouldn’t surprise me.

that blog entry was 8 years ago

Most of the stuff is written as plain HTML with minimal CSS and tables to create the look and feel. This was because it was originally made to be Fresco/Oregano friendly, and more recently (by a tenuous definition of “recently”) for NetSurf.

It probably needs a big overhaul, but not only am I lacking in round tuits, I also don’t want to end up with a farce like this site’s GitLab that simply doesn’t work with the most widely used RISC OS browser.

I notice that it told me the IPv6

Yup, it’s been TLS and IPv6 friendly for a while now, eight years for the padlock and almost exactly four for the BigNums. Plus I had some fun messing with the DNS record “just because”.

Maybe some day I’ll see my IPv6 address show up in Iris… ;)

Should probably have addressed the issue when HTTP deprecation was announced in 2014, not leave it to the last minute!

Indeed.
If you all cast your minds back, you will recall previous instances of me pointing these issues out.
It’s just that the run toward the wall is coming rather close to the painful bit now.

I may have missed the point completely (as often), but isn’t !ConvText a handy tool for such replaces? Type http⁵⁸//:https:// as a single script line and drag the root directory of your webpages to the iconbar icon. ConvText will then process every file in every subdirectory recursively.

Yes.

coming rather close to the painful bit now.

Cue somebody waving sixty four coloured pompoms. ;)

drag the root directory of your webpages to the iconbar icon.

The problem there is that it is not held on RISC OS … and it’s a sprawling mess and, really, much of it needs to be thrown in the bit bin.
The less fancy plain main page now omits quite a few things, and those omitted things will be first against the wall when the digital chainsaw starts up.

The problem there is that it is not held on RISC OS …

Ah, I was looking from the point of view of a local copy that is then uploaded for use.
Still, XENU does allow for checks via FTP of orphaned files. So cleaning the bottom of the digital litter tray is easier.

This was originally about people updating what exists to remove the HTTP based issues into non-issues, and seems to have drifted to site rebuild.

drag the root directory of your webpages to the iconbar icon.

Notepad++ is your friend. You can use Replace in Files recursively.

it’s a sprawling mess

Mine too, but it’s now a sprawling mess cleared of all the issues Steve very kindly alerted me to. Not, I hasten to add, fixed using the Pi – fixed using the Mac, where grep & perl did the necessary very easily. Much as I love RISCOS, I only use it where it’s the best* horse for the course…

• Where best often means most affordable or most familiar.

There’s a local copy, sort of ¹, just most of it is not on RISC OS. ;)

I threw together some PHP on my phone this morning. There are quite a lot of http links, but the problem I’m finding is the number that simply don’t exist any more.

I think I might tidy back to ~2020 and just leave the rest. ² Rather than cleaning the litter tray, I’ll just give it a shake.

¹ The blog is written on RISC OS/PC/portable/tablet in an editor and uploaded directly usually by adding to the top of an active file and then copy pasting that bit into the browser; the rest is either on the PC (active things) or DVD-Rs (older stuff). Periodically I pull a full site copy and dump it on DVD-R, I ought to do another one soon. This is in addition to Rob’s own cron backups.

² Because I know me. I’d disappear down a rabbit hole of trying to find alternative links or wayback references, and that’s really not a hole I wish to fall into. Life’s too short.

I may have missed the point completely (as often), but isn’t !ConvText a handy tool for such replaces? Type http⁵⁸//:https:// as a single script line and drag the root directory of your webpages to the iconbar icon. ConvText will then process every file in every subdirectory recursively.

Another tool that can be used to do that is WebChange – which works in a slightly different way to ConvText (and because it’s only a simple search and replace, the Windows version will work as well if that’s where a local copy is stored. And the Windows version also works under Wine, IIRC – so Linux systems as well).

However, that approach using ConvText and WebChange isn’t suitable for the problem Steve highlighted.

In both cases that will find every link that begins http and make it https – which may break links to external sites that are only http¹. The issue is embedded page content (for example images, frame/iframe content) that is loaded from a http link into a https-served page. That requires something a little more nuanced than either of those two are capable of.

WebChange can do more powerful search/replaces than the basic one described (don’t know about ConvText) but it can’t check if any given replace is actually right, based on where the intended content is held. It might be that any such content is held somewhere served via both http and https, for example, in which case the search and replace solved the problem, or it might be somewhere that’s http only, in which case you’ve just b0rked the page that loads it – and if you have a big site, you might not even realise you’ve broken some pages.

¹ http only sites is another issue entirely, and it will become more and more of a problem. I know some of mine will be affected, but IIRC the hosts for most of mine only give the first couple of certificates free, then it’s £££. I’ll deal with it all when the problem is a little more immediate. 8)

I threw together some PHP on my phone this morning.

It’s up now, if anybody is interested.

In both cases that will find every link that begins http and make it https – which may break links to external sites that are only http1

Yep, that was part of what I was encouraging people to check – the external links to sites like, Gavin Wraith ===> no https configured.

The issue is embedded page content (for example images, frame/iframe content) that is loaded from an http link into a https-served page.

The current totally-in-your-face issue is the embedded content on HTTP links, it will go more wide-ranging and any HTTP linked stuff will have problems.

The main thing is for everyone to identify what their issues are and start to address them.

Like the StrongED site for example where the host www on the domain stronged.iconbar.com cannot use the *.iconbar.com certificate that covers all the iconbar.com hosts, however the host stronged on the iconbar.com domain is just fine.

Edit: I just realised some people may not follow that, and understand what the host and domain segments are and that the certificate has to specifically mention the domain (when a wildcard cert is used) or the specific host(s), or a combination.
Basically, start at the right of the FQDN and each dot represents the subdivision of a domain into subdomains, so iconbar.com is a subdomain of .com or a single host called iconbar in the domain .com

So if the certificate is valid for all hosts in iconbar.com, i.e.wildcard with *.iconbar.com then unless you mention the *.stronged.iconbar.com subdomain in the SAN of the certificate then you can’t use it for a host called www in the stronged.iconbar.com subdomain.

It’s up now, if anybody is interested.

I see my throwaway comment about the “digital litter tray” found a home :)

BTW.

Not all links could be converted. Those remaining on http-only are: misc.vinceh.com, starfighter.acornarcade.com, 8bs.com, www.stronged.iconbar.com, PlingStore, and various radio streams.

You can convert the stronged link – you just need to omit the www. when you change it to https. Ref. the dibble about domain name structure earlier.

WebChange can do more powerful search/replaces than the basic one described (don’t know about ConvText) but it can’t check if any given replace is actually right,

Hmmm, interesting, the WebChange site linked from the www.softrock.co.uk page is not an HTTPS site.
Thus illustrating the point Vince made, that simply changing the HTTP link doesn’t magically change the target site to be HTTPS

Hmmm, interesting, the WebChange site linked from the www.softrock.co.uk page is not an HTTPS site.
Thus illustrating the point Vince made, that simply changing the HTTP link doesn’t magically change the target site to be HTTPS

Yes. To be honest, though, that being a subdomain of softrock.co.uk was only ever a quick fix to solve a problem. I decided to drop the webchange.co.uk domain, but when I cancelled the renewal I had quite a long time ahead of me to incorporate it into the Soft Rock Software site.

Me being me, though, I never got around to it until someone pointed out that the link was now dead – so I quickly created the subdomain and uploaded what was on the old domain, then changed the link accordingly.

I could do another quick fix, I suppose. Maybe I will later today.

I could do another quick fix, I suppose.

One for your blog too. ;)

One for your blog too. ;)

Oh, you mean the “posts” subdomain, :) I’m sure it’s all a case of round tuits being on backorder.

One for your blog too. ;)

Oh, you mean the “posts” subdomain, :) I’m sure it’s all a case of round tuits being on backorder.

I think Rick meant misc.vinceh.com there – unfortunately the only ‘quick fix’ I can apply to that is to spend some money, so that goes back to my footnote in yesterday’s post to this thread.

As for the posts subdomain of softrock.co.uk, yes, I forgot about that. I might be able to fix that fairly quickly as well, if the options available to me with the CMS I use for that allow it. I’ll have a look later – I’ll have to make some changes to the main site (on whichever RISC OS computer I have the local copy – which is what I need to do or WebChange anyway), as well as logging into the system on one with a capable browser. I have more pressing things to do right now.

Right, the ancient WebChange page is no longer on a subdomain – I’ve moved it to a directory within the products section instead (and taken the opportunity to fix all the links to its old website). As for posts.softrock.co.uk – I completely screwed that one (I think I changed the wrong things in the wrong order) and I’m not going to mess around trying to fix it now, so I’ve just removed the links that lead into it all.

At the risk of causing thread drift, this seems to be relevant to a website I help maintain. It was entirely HTTP. We set up an SSL certificate and now addressing it as https also works.
It is suggested that I need to do something so that accesses of http:// redirect to https://, and this might be in the .htaccess file.

Any advice from you experts out there?