Broken domains? Oy.
Opened this issue · 9 comments
I have not been able to reliably get to a bunch of my sites that use HTTP this morning. For example, feeder.scripting.com, a site that I use to test feeds. Also xmlrpc.com. It's possible that something broke overnight in my server. Or Digital Ocean is having a problem? Doesn't seem like it's something Google is doing to punish me for using HTTP, though that is always the fist thing that comes to mind. I tried moving the XML-RPC site to a different server, but the problem follows it. No changes have been made to the site in years. Not exactly what I had planned to be digging into on a nice (but cold) Sunday morning in the mountains.
When I try to go to http://xmlrpc.com/ I somehow get redirected to https://www.xmlrpc.com/. Not something I would do, since the site is served via HTTP and I don't like www subdomains.
I notice a weird thing in the DNS for xmlrpc.com.
I'm 99% sure I did not put that there. And I have no idea what it means.
Is this somehow indicating to someone that this domain supports HTTPS? It doesn't. It's a really old site, goes back to 1998 or so.
I'm going to delete that entry and see if the situation improves. I'm also going to ask ChatGPT about this.
No help deleting that weird entry.
Then I tried
curl http://xmlrpc.com/
on a server and on my desktop, and in both cases it correctly returned the html from the xmlrpc.com home page.
BTW, all on its own, the feeder.scripting.com link now works.
ChatGPT suggested clearing the browser cache, and I did, and now the redirect to HTTPS is gone, but it's still redirecting to www.xmlrpc.com.
I added a nice image to the scripting.com post about this. :-)
This is what I get at http://xmlrpc.com:
And this is what I get at https://xmlrpc.com:
Not sure why HTTPS is not redirecting to HTTP but above styling problem appears to stem from trying to load CSS file via HTTP from a HTTPS page. See:
@donpark -- i moved it to an HTTPS server, that seemed to fix the other problems, and created some new ones, which I just fixed (I think).
Okee. You likely know this already but HTTP[S] redirect is app level operation so 1) DNS can only help by pointing at the IP of the app (web server), and 2) the rest is up to web server settings or HTML meta tag.
Don, I know far more than I ever wanted to know. ;-)