This is my first Symfony bug report! I'm working with v2.3.4, and the relevant code in master branch hasn't changed since that release.

Yesterday I was building a Silex controller that generates images, and I hoped to use HttpCache so I could delay generating and storing images the right way in the web root.

Using Symfony's built HttpCache\Store class, I found that the method Store::generateContentDigest() and Store::save() were calling BinaryFileResponse::getContent() which returns FALSE. (So does StreamedResponse, so I assume this problem occurs in that case too.)

However, the content digest returned still has a value of en, which determines the save location of the cached response. I think the checks in Store::save() all pass because this directory exists if any prior responses have been successfully cached.

When the application handles other requests for the same file, it considers it a cache hit even though there is no saved content. I don't know if this is related to the code comments in Store::lookup() about returning null and purging the entry from the metadata store.

Ideally, the HttpCache would cache even streaming responses, but this may only have an inelegant solution. Since actual reverse proxy caches like Varnish would be able to cache the streamed response, I don't want to avoid setting appropriate cache headers on the response in my application. I guess HttpCache should refuse to store metadata when Response::getContent() returns false.