bigsite

Yeah, I’ve never had an issue like that but, from what I understand, PHP as a module will execute multiple times in the same child. The same child is reused up to the specified Apache server limit.

At any rate, I’m still scouring the code for possibilities. RSS feeds appear to get cached with legacy caching and I’ve already got a pretty good grasp on how the plugin functions (more or less). I’m definitely not a fan of the /cache/blogs/ directory structure since over half of the written directories there appear to be hacking attempts and 404 errors. The /supercache/ directory structure is a lot cleaner.

@horoscopes – A caching plugin is absolutely necessary if you want more than a small handful of visitors to be able to view the website. Especially on shared hosting where you don’t want to get kicked off for consuming too much CPU.

WP Super Cache is built upon WP Cache 2, the latter of which we view as a fairly stable plugin but it unfortunately hasn’t been updated since 2007 to reflect all the changes to WP 3.0. But the web server or one of the other upgrades caused the issue. I fixed it by simply bypassing WP and doing a .htaccess redirect. Which also happened to eliminate the “WP internal redirect to the root regardless of path” issue that I didn’t like, which should boost our site’s SEO a bit.

I’ve found the problem – WP Super Cache was installed right around the time we also dropped in a whole bunch of other upgrades, including an Apache upgrade. Running Wireshark, I get:

GET / HTTP/1.1
Host: https://www.domain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-US
Accept-Encoding: gzip, deflate
Cookie: __qca=P0-1371044966-1295985089624
Connection: keep-alive

HTTP/1.1 301 Moved Permanently
Date: Tue, 25 Jan 2011 22:57:53 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/1.0.0c DAV/2 PHP/5.3.5
X-Powered-By: PHP/5.3.5
Vary: Accept-Encoding,Cookie
X-Pingback: https://domain.com/xmlrpc.php
Location: https://domain.com/
Keep-Alive: timeout=15, max=500
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

And nothing after that – the connection terminates (FIN, ACK). This is technically an invalid response and Safari is responding appropriately. Safari is expecting a chunked reply, gets none, and errors out. Other browsers are seeing the ‘Location’ header and do a redirect regardless of the rest of the reply.

Fixed the issue with a rule before the WP Super Cache rules, thus bypassing whatever WordPress (or the plugin or some combination) is doing wrong:

RewriteCond %{HTTP_HOST} https://www.domain.com
RewriteRule ^(.*)$ https://domain.com/$1 [R=301,L]

So, definitely off-topic for the Unicode issue for this thread.

Hmm – application/xml shows up first in the Accept headers for Safari. text/html is usually first in most other browsers. The ordering might cause problems. I’m going to dig deeper to see if I can trace the source of the problem.

I agree – it is pretty hard to get any response for obscure questions around here. WP 3.0 in sitewide mode is basically WPMU, which very few people run – so support is limited. switch_to_blog() has been around since WPMU for a long time but, if you do anything intensive with it (e.g. scanning hundreds of blogs), it will chug extra RAM and take a long time to process. If you plan on doing anything serious with the homepage “blog”, cache each section in the WP database using a cron job. I’ve got a cron job that takes 12 seconds to execute that regenerates the necessary (serialized) pieces for the homepage blog. I wouldn’t want to drop any of that code on the homepage because it would kill the server.

Another possibly related problem: The automatic redirect from ‘www.domain.com’ to ‘domain.com’ works in all browsers EXCEPT Safari with this plugin. I get:

“Safari can’t open the page “https://www.domain.com/”. The error was: “unknown error” (CFURLErrorDomain:303) Please choose Report Bugs to Apple from the Help menu, note the error number, and describe what you did before you saw this message.”

Escape strange characters with a backslash ‘\’. For instance, ‘#’ is a comment character, so escape it as ‘\#’. Password should be in quotes “your password here”.

I just thought of something regarding this issue. Apache runs ‘x’ child instances and handles some number of requests before terminating the child process. PHP running as a module runs within these processes. Is there something about this plugin that is not PHP module-safe (i.e. not reentry-safe)? If I send a request to the server, I don’t know what Apache process is going to get the request but if any one of those processes starts acting “weird”, it will continue for future requests to that same child until the number of connections reaches the maximum number configured for Apache in httpd.conf.

I’ve been scouring the code for something that seems odd but haven’t found anything blatantly obvious yet. It definitely has to do with RSS feeds cross-pollinating to posts though. An RSS feed from a blog on our site being pulled onto our homepage was just affected – pulled the wrong RSS feed.

Another slightly related problem: The ‘supercache’ directory contains subdirectories for ‘domain.com’, ‘domain.com.’ (extra ‘.’), and ‘www.domain.com.’.

I just got it to happen to me one time on a single post. But I reloaded the page and that “fixed” the problem.

I was also just informed that RSS feeds have not been working properly since activating this plugin. So this plugin is somehow interfering with normal RSS functionality.

Apparently that didn’t work. It is still happening even with the development version.

I’m actually the right person to ask. A couple years ago, I attempted to write my own Unicode library and learned far more about Unicode than anyone likely cares to know. I got as far as attempting a collation implementation before I realized that I was WAY in over my head and ended up deciding the best solution was to use IBM’s implementation known as “ICU”.

Short answer: Unicode is evil. And when you want to reach as wide an audience as possible, you need to be able to target the three major OSes with server environments: Linux, Windows, Mac. The only guaranteed character set that will work on all three without issues is the printable subset of ASCII, which should also work on other similar OSes such as Solaris.

More detail: Modern file systems do support multibyte encodings but support varies widely. Each file system has several components that interact differently based on where the file operation APIs are being run from (kernel vs. user mode vs. some shell) and how well the software running understands the character set being used – most things use Unicode these days, but other multibyte encodings are also possible, which creates a huge mess for anyone writing new software to deal with. Security-wise and for caching purposes, encoding characters being written to the file system is a pretty good way to go as long as you only do a singular encoding and keep the allowed characters to a very specific set. Or use a fast string hashing algorithm. Not sure how hashing would translate to Apache .htaccess, but something to also consider.

By the way, I recently ran some performance tests using ApacheBench (ab) and you’ll be interested to learn that vanilla PHP as an Apache module can serve up content slightly faster than the same vanilla Apache installation serving up the same identical HTML file itself. I was a bit surprised to see those results – one would think that anything being served through PHP would be significantly slower. This observation may or may not prove useful to you.

Okay. I’ve uploaded the devel version and enabled “Extra Homepage Checks”. We’ll see if this fixes the issue. Thanks.