We have varnish out in front of one of our Matrix instances, and have found that we need to disable Varnish to get multiple page forms to preserve user input on any multiple page custom forms developed on that system.
Is there any technique that anyone in the community has for managing this setup? It’s a bit inefficient with any new form development having to add another exclusion.
As far as I know, we normally use the Type Code Specific screen under Cache Manager to disable caching and cacheable headers for custom form pages.
If you absolutely must try to deal with this at the Varnish level, one possible way is to call return(pass) on any requests with the SQ_SYSTEM_SESSION cookie. Note that this is, obviously, a very imprecise method, and how well it works will depend heavily on the nature of your site. Some sites will find it works with little disadvantage, other sites may find their hit rate (and thus performance) heavily impacted.
What we’ve been doing / had setup is that in one of the openresty nginx config files we have a location regexp that pushes everything through varnish except for excluded urls e.g.
## Everything goes through Varnish unless specified in following location block
## Data paths are excluded as per the regex below as these do not need to be proxied through to Varnish
location ~ ^(?!(/__matrix-data|/__data|/study/unistart/application|/assets/nested-content-assets/personalisation-framework/get-country)) {
...
}
which is workable for a few exclusions, but is threatening to become a mess with several new forms being created and needing exclusion.
Our full setup is Apache (frontend) <=reverse proxy => Nginx / Varnish / Matrix (backend) and I’d need to test to see if we’re getting any SQ_SYSTEM_SESSION cookies set for public visitors or not. I’ll also check if we have anything setup under the cache manager.
With effective reverse proxy caching in place, most public users shouldn’t ever get an SQ_SYSTEM_SESSION cookie, no. Their requests are being served from cache by the proxy (Varnish, in your case) and Matrix never sees them.
If they’re submitting a form, however, then the POST request should reach the Matrix backend, which would reply by generating an SQ_SYSTEM_SESSION cookie and passing it back to the client with a Set-Cookie header.
That said, it’s still probably best to try the Cache Manager first - using Type Code or Root Node settings is generally preferable to hardcoded proxy logic where possible, as it keeps all your caching configuration in one place (Matrix).