=> see commit: http://bit.ly/1wqwvbe)
With the strategy of cache Cache-Control (private cache for client browser) with a max-age of 2 minutes (120 seconds)
-
At the first refresh:
Notice the "private" mention. -
Calling the page again (don't do a force refresh, otherwise, your browser will bypass its cache):
Notice that the server is not hit at all.
=> see commit: http://bit.ly/1prET40
With the strategy of cache Cache-Control (public cache for Reverse Proxy / Gateway cache) with a s-maxage of 1 minute (60 seconds)
-
At the first refresh:
-
Calling the page again (60 seconds after the first call):
=> see commit: http://bit.ly/1vQHz2C
-
At the first refresh:
We can see that both the page /and the fragment have a stale cache. -
At the second refresh (less than 20 seconds after the first one):
We can see that both the page /and the fragment have a fresh cache (no need to regenerate the response). -
A the third refresh (35 seconds after the first refresh):
We can see that only the cached fragment is stale, time to regenerate a new response.
Nota Bene: You can take a look at the Symfony Profiler to notice the second request for the ESI (_fragmentxxxx
).
=> see commit: http://bit.ly/1wial91
Now you can have fun with all of that !
You may have notice that you can access the fragment directly from its url. Not that good uh?
Let's secure it with this, in the file security.yml :
access_control: - { path: ^/_fragment, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 } - { path: ^/_fragment, roles: ROLE_ESI }
Basically, if the client ip is 127.0.0.1 (the ip of your reverse proxy cache), the fragment is accessible, that way your RPC can get the missing fragment to replace the <esi:include src="xxx"> properly, otherwise, it is accessible by the user having the role ROLE_ESI (which nobody has so it's not accessible).