I've been experimenting with writing a REST style web service with Silex. When I tried to apply HTTP Caching to the web service, I discovered a couple bugs in the HttpCache feature of the HttpKernel component.

1. 304 responses always send "Content-Type: text/html; charset=UTF-8" header
   I noticed that when I turned on the HttpCache, the 304 responses I was getting always had "Content-Type: text/html; charset=UTF-8" even though the cached content was actually application/json or application/xml. The RFC says that a 304 "response MUST NOT include entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers." (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5). This is exactly the problem I am having. The Content-Type header is getting clobbered by an incorrect Content-Type header in the response.
2. Failure to invalidate cached entities referred to by the Location header
   My toy webservice uses the pattern described in this article (http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post) by Roy Fielding. The pattern uses POST to do a partial update of a resource. It responds with a 303 indicating that the client should refresh its representation of the parent resource identified by the Location header. When I tried using this pattern, I found that the parent resource was not getting invalidated. It was responding with the cached version which was out of date. I checked the RFC to verify that a cache should be invalidating cached entities referred to by the Location header and found verification here http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10. "Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present)."

I'll be submitting a bug fix soon.