Hello everyone,

I open this issue as a request for debate around the Symfony HttpCache and especially about its usage in development and production.

A few days ago, I stumbled upon the issue #4871 (HttpCache files getting too big) which is a problem only because the HttpCache is used in production.

Philosophically, the Symfony HttpCache was designed as both a development tool to get logs about the application HTTP cache configuration (hits, misses, etc.) and as in production environments as a simpler replacement for Varnish or other HTTP proxies (especially when the application run on a shared host).

While this usage in production is currently supported (but not recommended), it has limitations and issues (see https://github.com/symfony/symfony/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20httpcache%20). I would like to discuss the evolution possibilities in this RFC.

I see four options (but there are probably more, don't hesitate to propose):

1. We create two separated modes: one for dev and one for prod. The one for dev is integrated into the debug tools and the other one is designed for production.

   Pros: current installations can be migrated to the production version while having the debug tools for HTTP cache in the profiler.

   Cons: We have to deal with the usage of HttpCache in production officially, which requires maintenance and support. We also have to fix the current issues with HttpCache in production.

2. We don't change the code and simply explain in the documentation that the HttpCache is not designed for production. We could also add documentation about how to use it in development.

   Pros: easiy to implement, does not require code changes.

   Cons: I think it introduces more confusion than solves anything and is likely to don't solve the issues we currently have.

3. We don't change the code and keep the support of production but we list in documentation the known limitations and officially explain these won't be fixed.

   Pros: easiy to implement, does not require code changes and is clearer than 2.

   Cons: supporting HttpCache officially in production with limitations may become a problem to some people.

4. We deprecate the usage of the HttpCache in production in 3.2/3.3 and remove the possibility in 4.0. In parallel, we integrate it more deeply with the debug profiler in order to get the same debug informations (hits/misses/...) but in a debug environment (and therefore we become clear about the fact that the HttpCache should only be used in development). We could provide this HTTP cache debug features as an opt-in in 3.X and enabled by default in 4.0.

   Pros: it shows the idea behind the Symfony HttpCache and answer the issues with its usage in production (don't use it in production).

   Cons: current people having to use the HttpCache in production as they don't control their environment (shared environments for instance) won't be able to use an alternative and won't get any HTTP cache anymore.

I would like to get opinions. What do you think? Do you have an interesting use-case for this debate?