Samsung’s Android skin won’t let you tell it to forget a saved WiFi network unless it can see it right now. If it’s present, sure. If it’s out of range, it won’t let you tell it that no, you really don’t want it to automatically connect the next time you’re in range.

This is both annoying (your Galaxy S7 or Note 5 is going to keep looking for those networks all. the. time.) and a security risk (imagine someone sets up a rogue hotspot called “Starbucks WiFi” and you happen to park your car* or sit on a bench within range of it).

Note that the stock Android settings do allow you to fix this, with a Saved Networks section in the WiFi config. Samsung deliberately removed the feature** for some reason.

Apparently it used to be possible to remove saved networks using a third-party app, but new security protections in Marshmallow prevent that. (Ironic, that.)

Workaround (source):

  1. List all saved networks by going to Settings → Data Usage → More → Restrict networks. (This doesn’t let you remove them, just limit background transfers on them.) Take a screenshot if you have to.
  2. Remove the ones you don’t want anymore by tediously renaming your own WiFi hotspot to match each in turn [edit: you also need to match the security type (open vs WPA2)], removing them one by one in the regular WiFi settings, then renaming your hotspot back to its normal SSID.

It’s a pain, but at least it’s possible.

Update May 2017: The Android 7 update finally restores this capability directly in the Settings app, at least on the Galaxy Tab S2. You can now go to

Settings → Connections → Wi-Fi → Advanced → Manage networks

to remove saved networks of just turn off auto-reconnect on a case-by-case basis (so you can keep saved passwords). But for older Android versions, we’re still stuck doing it the long way.

*I once stopped at a Coffee Bean and left my tablet in the car. I don’t remember why I pulled it out when I got back in the car, but it had connected to the WiFi while I was grabbing my coffee. It couldn’t actually load anything but the login page because it was the real hotspot…but if it had been a fake hotspot, they could have intercepted or modified any non-encrypted traffic going on in the background.

**At best, Samsung forgot to include it when they wrote their own settings app years ago.

After switching one of my self-hosted WordPress blogs to all-HTTPS, I ran into an odd problem: Jetpack Related comments stopped working after a while.

After going back and forth with Jetpack support and my web host, it turned out the problem was with the SSL configuration on my site. Jetpack has to download a copy of your posts in order to calculate recommendations, and it uses libcurl to do that. Curl has stopped supporting the RC4 cipher in SSL connections because weaknesses have been found in it…and that’s what my server was using! (Ack!) I assume it was an old compatibility setting that never got updated.

Jetpack needed to reindex the site, but couldn’t retrieve anything, so it got stuck on “Indexing request queued and waiting…” Disconnecting and reconnecting didn’t work. Jetpack thought it was connected, so it didn’t report an error. (I assume it uses a different library for some things.) Pages were loading the script and the placeholder, but didn’t have suggestions to put there. And of course it wasn’t done indexing, so it didn’t offer a reindex button on the debug page.

What to do:

SSL ciphers are a server configuration setting, not a problem with your SSL certificate, so you don’t need to revoke and reissue the cert. If your hosting provider manages your server, you can ask them to disable RC4. If you run your own server, you’ll need to look up how to disable RC4 on IIS, Apache, NginX, etc. You can verify your site’s settings at Qualys’ SSL Server Test: Look for RC4 in the results and see if it’s labeled Yes or No.

If Jetpack doesn’t start indexing after you change your config, try turning off the Related Posts module and turning it back on. It only took a few minutes before recommendations started appearing on the site again.

There is one downside, which is that some older browsers (specifically Internet Explorer on Windows XP) may not be able to connect. As always, it’s a trade-off.

When I started the category clean-up project a while back, I decided to start monitoring 404 errors on the blog to see if I missed any incoming links that needed to be redirected. I was surprised to find that the logs showed no 404 errors at all from within the blog structure. Images, sure, but no articles, no tags, no categories. This seemed a bit hard to believe.

I tested it by deliberately hitting a non-existent page, and was dismayed to find that Apache logged the hit as 200 (OK).

Crap! a WordPress update must have broken 404 handling! How long had this been going on? I’d better manually insert a header in the 404 page!

That seemed to work, as far as Chrome’s Developer Tools and curl -I were concerned. I didn’t have time to follow up on the logs right away, so I checked back later…and the logs still showed 200 OK, not 404.

WTF?

It turned out that, when served through WordPress, Apache was sending a 404 code to the browser but logging a 200.

Probably a plugin, right?

Not so. I installed a fresh copy of WordPress on a test site and discovered something interesting: 404 codes were logged correctly when using the default /?p=123 permalink structure, but if I changed it to anything readable like /yyyy/title or even /title, the problem recurred.

A little more investigation: I skipped WordPress entirely and just hit a PHP page that served up a 404. When I hit it directly, it logged correctly. But when I used WordPress’ mod_rewrite rules to send a hit to that page, it logged a 200.

So clearly, it was something about mod_rewrite. I don’t run my own Apache server these days (my department at work is mainly a Windows shop), but I was pretty sure it didn’t work that way back when I did.

So I did some testing of different configurations at home and on my webhost. Direct hits always logged the correct status, but with a rewrite rule, here’s what I found:

FastCGI & CGI on DreamHost show 200/404.
mod_php on home box shows 404/404.
mod_php on DreamHost shows… 200/404.

At this point I figured there was no point setting up a CGI or FastCGI-based PHP environment on my home box, because it was clearly something about Dreamhost’s Apache configuration.

It does log correctly if you use ErrorDocument directive to point 404 to a PHP script. But IMO that’s abusing the error handler mechanism to do something it wasn’t meant for. (Not that I haven’t done it myself, but only on older IIS servers where ISAPI Rewrite and URL Rewrite weren’t available.)

I’ve added a custom logging snippet to my WordPress 404 page. There are other ways I can capture the data, but that seemed like the least overhead for now.