The Case of the Missing Trailing Slash and the Nefarious Port 16080

I recently had to deal with a very oddball problem at work. We are running a web server with Mac OS X Server, which we recently upgraded to version 10.4. After the upgrade, everything seemed to be working fine...mostly. Except for one thing.

If you were to type, in your browser, www.website.com/resource/, you would get to the desired resource just fine. Note that I have bolded the trailing slash, mostly because I can't bold it in the next example because it won't be there.

if, on the other hand, you typed www.website.com/resource (no trailing slash), which is actually the far more common behavior, the URL would be transformed into www.website.com:16080/resource, and the browser would stall waiting for a server that was never going to fill the request.

Thoroughly stumped, I turned to Google. It seems this is a problem that others have had as well, which is a relief to me because it means I'm sailing in charted waters. Everyone said that turing off the Web Performance Cache fixed the problem. So, I tried it; I went into server admin, edited my virtual host, and unchecked the "Web Performance Cache" checkbox. Lo and behold...the problem persisted.

More Googling revealed the nature of the cache. It is a feature specific to Mac OS X. When it is enabled, a caching daemon runs and sits between Aoache and the outside world. It is the cache process that serves all of your pages, fetching them as necessary from Aoache and serving them from its in-memory cache if they are available. Ok, that's kind of neat. I also learned that the cache process communicates with the server process over port 16080. Port 16080...the same port as shows up with every trailing slash...it's gotta be the performance cache...what gives?

I wanted to see if my turning off of the cache was actually taking in the OS. Googling to discover the process name (it's webperfcache), I came across this document that explains that the process would be running as long as the cache is enabled in at least one virtual host. I checked, and the process was indeed still running. We had multiple virtual hosts, so I checked the others, and sure enough, the cache was still on. I disabled those too, and *POOF*! Our server functioned properly again.

Case closed!