About two months ago I moved my website between servers within the same hosting company. The old service was being hammered, so I moved to a better dedicated server blah, blah, blah. There was some fallout from this, mostly focussed on lost emails, but I figured it was pretty much over.
Yesterday I received two emails from totally separate people asking why I was blocking their company proxies from accessing my website. I wasn’t. One of the guys got his company to do “something” to their proxy (squid) and they were able to access my site again. The other is waiting for his network folks to check their proxy.
That incident prompted this quick post, just to let people know how things are…
The website is available from these URLs.
If you try to use the following URL, you will get an SSL security warning, but if you accept it, you will be bounced across to the proper HTTPS address.
- https://oracle-base.com (bounces to https://oracle-base.com)
From a Google indexing perspective, the main (canonical) URL is still “https://oracle-base.com”.
Q1: Do I plan to move over to pure HTTPS?
A1: Not at this time. It’s taken about 2 months to get my page views back to where they were before the move. That’s not super important for me, but if that loss in page views was because people and search engines were having issues with the site, that is not great. As I’ve said many times before, I do the site for me and the fact that other people like it is a bonus. Having said that, I would rather not annoy people by changing stuff every five minutes. 🙂 At some point in the future that move will probably happen, but it should be seamless. Redirects are a wonderful thing…
Q2: Does everything work on the HTTPS address?
A2: Almost. It’s not a super important issue for me at this time. As far as I can see, the main website and forum work fine. Currently, links to the blog fail on HTTPS. WordPress is kind-of anal about the main URL. You have to define the base URL and if you try and access it in any other way it is not happy. I did a quick search for solutions to this, but none were forthcoming. I’m sure it is solvable, but I can’t be bothered to spend any more time on it at this point. 🙂 There will no doubt be lots of internal links that use HTTP, so you might jump back to that by accident. I’ll fix these over time, but like I said, low priority at this time. 🙂
Q3: Does the site work with IPv6?
A3: Yes. I got an email soon after the move saying that IPv6 access was broken. The web configuration wasn’t the problem, since it was listening on the IPv6 address as well as the IPv4 one. I had simply forgotten to open the IPv6 ports for HTTP and HTTPS. Once that was done, life was good.
So as far as I know, there are no outstanding problems on my side that would prevent anyone accessing the site. If you think there are issues (you probably can’t read this) I would like to know, but I would suggest you check on your side first. By that I mean, check your browser cache and company proxy cache are not the problem.
Anyway, enough of the boring stuff. It’s the company financial year end today, so I have to make sure we don’t blow any tablespaces and do the odd backup… Fun, fun, fun! 🙂