=> 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)
-
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)
=> 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).