Three requests to my pricing page, three different session ids, and nothing on the page reads them
I sent the same page three requests this morning with no cookies attached, the way a monitor or a link checker would. Three responses, three different session ids, three different CSRF tokens, each one set to live for a day. The same response also says it must not be stored by any cache.
The pages either side of it, same site, same server, same deploy, hand out nothing at all and are served with five minutes of freshness and a day of stale while revalidate. The difference is not the page and not the traffic. It is which middleware group the route was declared in, which in my source is a word at the end of one line.
Then I went looking for what reads those two cookies on that page. Nothing does. The page carries no form and never prints the token into the markup, so neither cookie has a consumer until the visitor goes somewhere else. I watched the session store locally while sending five of those requests and it did not gain a single file. The id is minted, sent, and never asked for again.
Here is the check, and it is about two minutes. Take the pages you point ads or links at. Request each one without cookies. Look at exactly two response headers: whether anything is being set, and what the caching header says. If the first is present, that page is out of every shared cache in front of you no matter what the second one claims, and the clients collecting those identities are your uptime monitor, your link checker, every social preview fetcher and every crawler, none of which will ever send one back.
The part I got wrong is worth more than the finding. I assumed the pages that have to know who is asking were the ones behind sign-in. The one that had it was the pricing page, and its reason is real: a signed-in reader is sent somewhere different by the main button, and getting that wrong would send somebody who already has an account to a sign-up form. So this is not a mistake to fix by moving the route. It is a trade to make on purpose, page by page. A page can be cheap to serve to everybody, or it can answer the question of who is asking. There is no arrangement in which it does both, and the cost of finding that out late is that your busiest page has quietly been the expensive one.
If you run it, I would like to know which of your pages sets something, and whether you can find the thing that reads it.
Replies
the thing that mints it is probably middleware that ran before your handler. any call that touches the session object, even a read, is enough in most frameworks to force a set-cookie on the way out. since you already narrowed it to the middleware group, worth checking whether the auth layer in that group does a lookup on every request instead of only on protected routes.