Rails respond_to processes XML but caches HTML

The 'root' page of my site is rendered by the posts#index action. To support rss and html, I have a respond_to block that looks like:

 respond_to do |wants|
  wants.html 
  wants.xml {
    render :layout => false;
    response.headers["Content-Type"] = "application/xml; charset=utf-8"
  }
end

I also have a 'caches_page' set on the index page.

If someone comes to the site in a browser and just requests "/", then they get served the html version of the page, and Rails also writes a cached page for index.html

There isn't really any way to request "/" with a format of XML, but if I hit "/posts.xml" it renders XML and caches posts.xml (similarly if I hit "/posts" or "/posts.html" it will cache posts.html). That all works just fine.

Now for the tricky bit. If something requests "/" but has an accept header like:

Accept: text/xml

Then Rails will process it as XML (probably correct), but CACHES it as html, destroying my cache. The next visitor to the site will be forever server an html file that actually contains XML. Here is the Rails log message proving this is happening:

Started GET "/" for 127.0.0.1 at 2010-11-30 20:47:27 +0000
  Processing by PostsController#index as XML
  Post Load (1.4ms)  SELECT "posts".* FROM "posts" WHERE ...
Rendered posts/index.xml.rxml (243.8ms)
Write page /..../index.html (0.6ms)
Completed 200 OK in 423ms (Views: 244.8ms | ActiveRecord: 1.4ms)

Is this a bug? I browsed some of the code, and the 'page caching' code doesn't consider the processing format of the request - it just parses the URL to see if there is a :format extension. If no extension is found, it use the defaul (html). This problem occured on my live site - I suspect it was a robot that came in with the text/xml header, but anything that does this can break a sites cache pretty easily.