I had a similar problem (with all 3 scenarios) and successfully used the following strategy with Symfony's built-in reverse proxy:
If you are using Apache, update .htaccess to add the environment variable for your application to the http cache from (NOTE: the environment automatically adds REDIRECT_ to the environment variable):
# Add `REDIRECT_CACHE` if API subdomain RewriteCond %{HTTP_HOST} ^api\. RewriteRule .* - [E=CACHE:1] # Add `REDIRECT_CACHE` if API subfolder RewriteRule ^api(.*)$ - [E=CACHE:1]
Add this to app.php after creating an instance of AppKernel :
// If environment instructs us to use cache, enable it if (getenv('CACHE') || getenv('REDIRECT_CACHE')) { require_once __DIR__.'/../app/AppCache.php'; $kernel = new AppCache($kernel); }
For your โstaticโ APIs, all you have to do is take the response object and modify it:
$response->setPublic(); $response->setSharedMaxAge(6 * 60 * 60);
Because you have a token, user token, or security, Symfony defaults to $response->setPrivate() .
As for your second point, REST conventions (as well as reverse proxy recommendations), GET and HEAD requests are not intended to change between requests. Because of this, if the content changes based on the registered user, you must set the response to private and prevent caching at all for the reverse proxy cache.
If caching is required for speed, it should be handled internally, not by a reverse proxy.
Since we did not want to enter URLs based on each user role, we simply cached the response inside the role (using Redis) and returned it directly, rather than letting the cache (mis) process it.
As for your third point, since HTTP and HTTPS traffic fall into the same cache and the responses have shared / privacy settings and caching settings are explicitly set, AppCache serves the same response, both safe and insecure traffic.
I hope this helps, as it does for me!
source share