Duplicate of T97096 (I'm on my phone or I'd close it as such).

Note it doesn't really depend on "logged in", just on the presence of anything matching ([sS]ession|Token)= in the Cookie header:

$ curl -is 'https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&uselang=content&smaxage=10' -H 'Cookie: xToken=1;' | grep -i cache
cache-control: s-maxage=10, max-age=0, public
x-cache: cp1067 pass, cp1053 pass
x-cache-status: pass

Chances are that to avoid this we'd have to figure out how to reliably differentiate requests that actually depend on the session (including the session user's identity or preferences) from those that don't and then somehow avoid setting Vary: Cookie for the latter.

Yeah, it seems like Varnish just looks at the presence of the Vary header.

Can't the API just ask the modules via some overridable method API (like isReadMode etc)?

No, because the module might not know in the first place. Look at the crazy things that cause trouble for T127233: Endpoints which do not need to authenticate users should set MW_NO_SESSION, it's basically the same thing but without the luxury of being able to actually define MW_NO_SESSION and blacklist all session access.

A rough idea might be to add code (probably in SessionBackend and User::loadFromSession()?) to set some flag to indicate that the session was accessed, without triggering from whatever Setup.php does. Then make sure nothing can change that flag between when you check it to set the Vary header and when things are actually output.

In T155314#2945672, @Anomie wrote:

A rough idea might be to add code (probably in SessionBackend and User::loadFromSession()?) to set some flag to indicate that the session was accessed, without triggering from whatever Setup.php does. Then make sure nothing can change that flag between when you check it to set the Vary header and when things are actually output.

That wouldn't guarantee that the same URL reliably always or never emits Vary: Cookie. E.g. asking data from normal vs. revdel'd revision - from the API's point of view there is not much of a difference.

Maybe there could be a separate non-authenticated API endpoint?

In T155314#3076735, @Ottomata wrote:

I'm not sure how to triage this. Does something need to change on the varnish end? Or just the change @Anomie suggests in MW?

Setting (or not) Vary seems to be the right way to tell Varnish whether to cache or not, and the Varnish docs claim it's honored, so there shouldn't be any need for change.

Change 341502 had a related patch set uploaded (by ema):
[operations/puppet] cache_text varnishtest: vary cookie

https://gerrit.wikimedia.org/r/341502

Change 341502 merged by Ema:
[operations/puppet] cache_text varnishtest: vary cookie

https://gerrit.wikimedia.org/r/341502

In T155314#3077838, @Tgr wrote:

Setting (or not) Vary seems to be the right way to tell Varnish whether to cache or not, and the Varnish docs claim it's honored, so there shouldn't be any need for change.

That's right. I've added a varnish test case to test/document Vary: Cookie handling.

This seems to WAI, only responses for anons are cached in varnish, anything left to do?

In T155314#3452263, @fgiunchedi wrote:

This seems to WAI, only responses for anons are cached in varnish, anything left to do?

Fix api.php to not vary on cookies when the response did not depend on session data. Or decide that that is unrealistic to detect and decline.

This is not a huge deal right now as clients have to explicitly ask for API responses to be cached in Varnish (although some tools do that, e.g. MediaViewer, and become slower for logged-in users as the result of this bug); depending on the outcome of T122867: Evaluate the feasibility of cache invalidation for the action API it might become a bigger obstacle in the future.

Anything to still pursue here? It's been a few years. Obviously, one path towards fixing these things is to not emit Vary: Cookie from API endpoints that return only publicly-cacheable info.