I redirect traffic to my root domain and www subdomain to this blog, with the request path unaltered. It looks like this:
http://donovan-jimenez.com/* => http://blog.donovan-jimenez.com/$1Since my blog is hosted on blogger and rewrites are happening at CloudFlare's servers, I should never see traffic to my origin server for this these types of requests. However, about every week I would see requests for / and /robots.txt (search bots) and the occasional vulnerability scanning request (e.g. /mysqladmin/login.php). It bugged me that CloudFlare was not properly rewriting these.
http://www.donovan-jimenez.com/* => http://blog.donovan-jimenez.com/$1
InvestigationI used tcpdump to collect HTTP requests to my origin server and then waited for my server logs to indicate a problem request was received. The reason turned out to be very disappointing. The Host header of the HTTP request just needed to be of different case than the page rules. An example problem request:
GET / HTTP/1.1I quickly verified this for myself using a number of mixtures of case (e.g. Donovan-Jimenez.com) with telnet.
This hadn't occurred to me to check originally, since I assumed page rules would normalize the client specified host before applying rules against it. DNS resolution is case insensitive, thus the host for an HTTP request is intrinsically insensitive as well. It's also obvious that CloudFlare is already doing this in other components, or the request would never have been routed to my origin server in the first place.
SolutionNone, so far. I've submitted a ticket to CloudFlare to get their take on what I'm seeing. My hope is that they'll agree with me that it needs to be normalized and patch their system.
Updates7/9/2012 - CloudFlare support has confirmed the issue with an engineer, and they'll be working to fix it soon.
10/1/2012 - No longer seems to be an issue. I do not have an exact date for when they rolled this out as they didn't update my ticket.