I just posted about the following confounding problem to the WP-Hackers list:
When running WordPress MU (tested in 2.8x and 2.9x) with the memcached object cache active, it refuses to respond to HTTP HEAD requests. The result of this is that head requests to check the mimetype of a linked file (as for setting the enclosure) or size (as the video framework plugin does) fail.
curl -I http://url.path
returns either an empty result, or (if fronted with varnish) a 503 error.
telnet site.org 80
HEAD /url.path HTTP/1.1
host: site.org
returns the same.
Moving object-cache.php out of /wp-content or commenting out one line ( $this->mc[$bucket]->addServer(...) ) solves the problem. Oddly, the problem occurs only when wp_cache_init() is called the second time in wp-settings.php (if I comment out that line, the problem disappears as well, even though the cache was initialized previously).
The problem occurs with multiple revisions memcache object-cache.php, including the most recent, on multiple servers with different versions of memcached.
I have not yet had an opportunity to test this with non-MU releases of WP or with /trunk/ (where it appears that calls to wp_cache_init() have been replaced with wp_start_object_cache() ), so there’s a good chance this is MU specific or fixed already, but in all my searching I haven’t been able to find any mention of the problem.