HTTPS forced on a page where it doesn't work

[Unix Ronin]

I have a HTTP/HTTPS problem on a single site. It's a webcomic, and the problem is that the site supports https, but the actual comic page doesn't work with https. The comic author has been unresponsive about fixing the problem, so I'm trying to work around it from my end.

My first thought was HTTPS Everywhere, or rather the PaleMoon specific fork, Encrypted Web. So the first thing I did was to figure out how to write a user custom rule to exclude the site, or at least its comic page. That didn't work. So then I disabled Encrypted Web altogether, and the page still loads as https: from my http: bookmark. So it's not Encrypted Web doing it, there's still something else I need to find.

I have a vague recollection of long ago finding a preference setting that tells Pale Moon itself to always open sites as HTTPS if supported. So I went through about:config line by line looking at every setting that showed as changed from default, looking for anything relevant. I found network.http.upgrade-insecure-requests and tried turning that off, but that didn't solve the problem either. I found noscript.httpsForcedExceptions, but I'm no longer using NoScript, so it can't be that. I found no other relevant-looking settings.

If I manually type the site URL, http://www.sssscomic.com/comic2.php, in the location bar, it opens as http: as instructed. But if I open it from a http: bookmark, something is still rewriting it to https:, and I can't figure out what.

Can anyone think of anything I might have overlooked?

[satrow]

"I'm no longer using NoScript, so it can't be that."

Add-ons don't necessarily 'uninstall' the way you seem to think they do. Tools > Restart in Safe mode, if that works, make a new Profile.

[Unix Ronin]

I can see that removed add-ons don't necessarily clean up after themselves. There's a lot of settings left behind by extensions I no longer use (see my next posted question, actually). However, I assumed that settings left behind in its own namespace by a removed extension would no longer do anything.

Nevertheless, I already tried adding the domain to the noscript.httpsForcedExceptions list, and that had no effect either. (Not that I expected it to, with NoScript not being present any more.)

[coffeebreak]

AFAIU, it's the extension that provides the code that gives effect to its own preferences. Once it's uninstalled, any leftover preferences should be just a visual annoyance. The only type of exception to this would be with an extension whose actual purpose wass to change the browser's own settings (eg. Pale Moon Commander). NoScript does not change the browser's settings, its preferences are purely its own.

With NoScript, after it's uninstalled I believe the important thing is to clear cache and cookies, and maybe restart for good measure.

But perhaps there's some other extension or other setting causing the problem...?
As recommended earlier, what happens in safe mode?

(If the problem is gone in safe mode, you'll know that it's not caused by a preference and is probably due to a currently installed extension.)

[MRCS4]

If you're using a VPN, mine has a Force HTTPS setting so that could be your problem.

[Unix Ronin]

Nope, no VPN in use.

I just found Restart in Safe Mode — on Linux it's on the Help menu.

[Unix Ronin]

Oh, wait ... this gets even weirder than I thought.

In safe mode, the http: bookmark for that comic still opens as https: ... but it works now.

Color me TWICE as baffled now. It's not that the site is broken and that page no longer works over SSL. It's that something active when I'm not in safe mode is breaking THAT ONE PAGE, but ONLY when loaded as HTTPS.

[Moonchild]

Clear your cache, cookies and in the "Clear recent history" window, also clear "site connectivity data".

[Lootyhoof]

As an aside:

My first thought was HTTPS Everywhere, or rather the PaleMoon specific fork, Encrypted Web.

That hasn't been updated or supported in years. Do use the later, much more supported fork HTTPS Always: https://addons.palemoon.org/addon/https-always/ (optionally paired with HTTPS Inquirer: https://addons.palemoon.org/addon/httpsinquirer/)

[Unix Ronin]

Thanks for that pointer, LootyHoof. Much appreciated.

[Unix Ronin]

Lootyhoof — Made that switch, no change in behavior.

Moonchild — cache, site connectivity data, cookies cleared; no change in behavior.

Coffeebreak — already established that it works correctly in safe mode, and that I was mistaken about the nature of the problem: it's not that the source doesn't work via a https connection, it's that when loaded over https — but ONLY when loaded over https — something is breaking that one page, and as far as I can tell, nothing else. I'm now trying to isolate what is breaking it. (A workaround would be to tell the browser to always load that url as HTTP, never as HTTPS.)

[coffeebreak]

established that it works correctly in safe mode
[...]
when loaded over https — something is breaking that one page [...] I'm now trying to isolate what is breaking it.

In an earlier post I linked to an article that explains what safe mode does (and doesn't do). Please read it. And...

If the problem is gone in safe mode, you'll know that it's [...] probably due to a currently installed extension.

You might start by checking your HTTPS Always rule set. What happens if you disable all rules? Or if you disable the extension?

More generally, you can troubleshoot by disabling/enabling your extensions one at a time to rule out which is causing the problem.

[Unix Ronin]

Yup, I tried disabling all extensions before, binary-search mode, inconclusively. I thought I'd ruled out it being an extension, which is why I went digging through preferences.

However, I just tried it again, and this time I found it: it's Adblock Latitude doing it. I must have somehow missed disabling it on the first go-round.

Why it thinks the comic is an ad, I have no idea. But of course, now that I know that, the solution is stupidly simple: just disable Adblock on sssscomic.com.

[moonbat]

Why it thinks the comic is an ad, I have no idea.

That's what ABL's (or any other adblocker's) logs are for - they will show you exactly what was blocked and what rule or filter caused it. Adblockers aren't magic - learn how to use filter lists and add or remove individual rules instead of just a binary on/off if it is blocking something it shouldn't.

[coffeebreak]

I found it: it's Adblock Latitude doing it.
[...]
of course, now that I know that, the solution is stupidly simple: just disable Adblock on sssscomic.com.

It would be good to know which adblocking rule is the cause.
I installed ABL and HTTPS Everywhere to a profile and forced HTTPS on the site, but haven't been able to reproduce any problem (meaning that the comic loaded and its navigation arrows worked fine).

Would you please help by answering some questions?

1. Which filter lists do you use? Please list all of them.
2. Do you also have custom filters?
3. Sssscomic has mixed active content which, when using HTTPS, the browser blocks unless you tell it otherwise. Was the mixed content unblocked at the times you experienced problems?
4. >the actual comic page doesn't work with https - What specifically didn't work (until you disabled ABL)? Don't explain or give reasons, just describe it.