On Tue, 2008-03-25 at 18:13 -0700, Ric wrote: > > Even then you have the same problem. A public response is a cache hit > > even if the request carries authentication. > > > Umm... only if it contains a "public" cache control token. That's the > point of the public token. That's why your backend should only add > this token to items that contain no personalization. Not what I meant. What I meant was 1. A unauthenticated request for the resource, causing a public version to get cached. 2. Authenticated request. This will see a cache hit to the previous cached public response. > But if we're authenticating via cookie instead, then the public > token > is sort of pointless and the private token may be more useful. Yes. > I believe this is incorrect. We don't care whether the *request* > contains a personalized cookie; we only care if the subsequent > *response* is personalized. The cache cares. It needs to be able to identify what to use for this request. > For example, even a personalized response > to an authenticated request may assemble several non-personalized > inline graphics, css, and javascript. Yes, but each of those is individual URLs and handled separate. If non-personal then make them public. > Maybe I'm missing something here, but I don't see a need for Vary: > Cookie for non-personalized content (unless one is doing some sort of > cookie-based content negotiation... shudder), and of course we don't > want to cache personalized content. No, but you want to provide a split-view on the same URL providing both a public copy for anonymous guests and a personalized copy for authenticated users. Regards Henrik
