Improve JavaScriptServlet client side caching strategy #327
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to improve client caching strategy for javascript csrf client.
Context :
In our usage, we inject the script on pages using a ServletFilter that build the <script> and add it in the outgoing html. At that time, we have session information about user which query the page and we can decide a particular client side caching strategy for the csrf javascript client code using a watermark (tag) in the URL. That tag is based on the MD5 of the JS generated for that particular client and can then be cached during the session.
If anything changes in the JS (including CSRF master token) the link won't be the same and not retrieved from browser cache.
The JavaScript servlet has been modified to take into consideration that query param (tag) and include a specific client cache header for that purpose.
When param is not used, the servlet now include a ETag with a must revalidate strategy that will compare existing client side ETag avoiding, in case of same hash, to send again the content but a 304 response status code.
Modifications are mainly :