More Technical Difficulties Resolved (The “Zip File” Problem)
In addition to last weekend’s troubles, SF Signal had some more technical difficulties that were encountered and resolved.
The problem? Some people were reporting on Monday that when they tried to browse to SF Signal, their browser was asking them to download a zip file. Rest assured that there was no danger for visitors. The problem was caused by a mis-configuration of a caching plug-in that altered the way our web server responded to URL requests. The problem has been fixed.
Here’s some more details about how events transpired:
- I thought it was strange that people were reporting zip file download attempts when accessing SF Signal because it did not happen to me. I mainly use the Chrome browser, so I immediately tried with other browsers. Although it did not happen to me when I used Firefox, it did happen when I used Internet Explorer. (I asked people who mentioned that they were affected, and they told me that they saw it with various browsers — Chrome, Firefox, IE, Safari…but I was only able to reproduce it with IE.)
- Trying to understand what was happening, I allowed that zip file download on my system and viewed the one file it contained (as harmless text). It was indeed the requested HTML file, just served up by our web server as a zip file. So…to be clear…there was no danger — the requested HTML file was being returned to the vistor, it was just repackaged as a Linux “tar” zip file.
- Using a web development tool, it looked like browser requests were asking for a zip files format. That was odd and pointed me to the behavior of the web server itself.
- I looked in our htaccess file and found several lines there about zip files and HTTP requests, apparently put here by the WP Super Cache plug-in. Ding-Ding-Ding! A bell went off in my head — I had tweaked these settings a few days ago to improve a separate performance issue with the site. Since I wasn’t seeing the problem with Chrome, I never saw an issue at the time…and then the weekend hack happened so that masked the problem even further.
- Even though I found a possible cause, I was unable to do anything about it because by then I had already passed it to our web host, Host Gator, on Monday morning and they requested that we not touch anything. I did call them back and pass along this new information, though.
- Monday night I received an email from them that the issue was resolved but they were unable to help because they were not able to correlate the infected files because they were modified (fixed) by me. This is odd because they were responding to the security issue, which had already been fixed. It appears the phone tech (a super-polite gentleman, just like all the phone techs I’ve dealt with there ) did not properly communicate the issue to the Security team.
- Now that the web host had “resolved” the issue (or, were apparently not looking at the real issue), I took it upon myself to uninstall then re-install the WP Super Cache plug-in, leaving the defaults settings as-is. The settings page even warns that not all modes — including the one I had enabled — was not necessarily compatible with all web servers. So chalk this one up to website operator error. (That’s me.)
- I have verified with others that the problem no longer appears. So it looks like this has resolved the issue.
Again, apologies for the inconvenience and thanks to everyone who took the time to let us know and lend their much-appreciated assistance.
Filed under: Meta
Like this post? Subscribe to my RSS feed and get loads more!