Apparently Rails 2.1 has the nifty ability to throw a 500 Internal Server Error with the message “IP spoofing attack?!” under certain circumstances.

Unfortunately, those circumstances include a common Apache/Mongrel deployment and Yahoo’s crawler, Slurp, trying to index your site. It’s possible Apache/Mongrel isn’t required; I’m unsure.

The key is that Slurp includes both a Client-IP header (HTTP_CLIENT_IP by the time it hits Rails) and an X-Forwarded-For header (HTTP_X_FORWARDED_FOR). When both are present, Rails assumes something evil is happening and voluntarily dies. Neat.

Such a header can be relied on only if it was set by a trusted proxy. Otherwise, it’s hard to know if it was spoofed. The difficulty is for Rails to know which one, if any, was set by a trusted proxy.

I deploy Rails in a common Apache w/mod_proxy_balancer and Mongrel setup. Apache uses X-Forwarded-For natively, so that’s the one I want to trust. To make Rails happy, I’ve just told Apache to delete the Client-IP header if present.

Adding RequestHeader unset Client-IP to the virtual host configuration seems to do the trick.

This does require mod_headers to be enabled in Apache.