Do not set anonymous session to avoid lost cacheability on redirection

We changed to a hash in the URL instead of a query param, because in some cases the cache is based on the query params.

That worked perfectly for me, thanks!

Thank you @artem_sylchuk

Can we get this committed?

Displaying the message using JS seems to work, but:

• I can't reproduce a new session being added to the sessions table when the message is set in Drupal
• When setting the message using JS, responses are still serving cache-control: must-revalidate, no-cache, private. That's probably because Drupal forms are uncached. I know that's being worked on → , but for now they aren't cacheable

Having said that, I don't really see the advantage yet of this new approach. Am I missing something?

@dieterholvoet I just tested on a fresh D11 and while you are correct the DB entry does not exist (I'm not sure when this changed or is dependent on env setup), the session cookie does exist.

The problem isn't that the form itself is uncached, but that with the session cookie all subsequent requests are uncachable by page cache until that cookie is deleted or expired. For a lot of large sites, this usually means bypassing CDN's as well as extra strain on the server while it serves dynamic page cache to anonymous users that would have otherwise been page cached without the cookie.

Hopefully that clears things up.

Alright, thanks for the explanation, makes sense. I updated the copy a little bit, seems good now. This does still need tests though.