Per the official HTTP semantics[1,2], what you say is not true: the only header that’s (effectively) always part of Vary is Authorization, the rest are at the o

Per the official HTTP semantics[1,2], what you say is not true: the only header that’s (effectively) always part of Vary is Authorization, the rest are at the origin server’s discretion; so don’t set Vary: Cookie on responses corresponding to static assets and you’re golden. The article only says that some (all?) browsers will disregard this and count Cookie there as well. Even still, the question is, what’s worse: a cacheable request that has to go through DNS and a slow-start stage because it’s to an unrelated domain, or a potentially(?) noncacheable one that can reuse the existing connection? On a fast Internet connection, the answer is nonobvious to me. [1] https://www.rfc-editor.org/rfc/rfc9110.html#name-vary https://www.rfc-editor.org/rfc/rfc9110.html#name-vary [2] https://datatracker.ietf.org/doc/html/rfc6265#section-3 https://datatracker.ietf.org/doc/html/rfc6265#section-3