mayeco / cache-app Goto Github PK

=> see commit: http://bit.ly/1wqwvbe)

• 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

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