- From: Shel Kaphan <sjk@amazon.com>
- Date: Tue, 20 Feb 1996 07:59:22 -0800
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: HTTP Caching Subgroup <http-caching@pa.dec.com>
David W. Morris writes: > > > On Mon, 19 Feb 1996, Shel Kaphan wrote: > > > Jeff writes: > > > confess that I am at a loss to think of an example where it > > > is unacceptable to store a particular field of a response > > > that is otherwise public, but perhaps I am simply being > > > unimaginative. > > > > > > > Set-cookie. > > I guess I share Jeff's difficulty conjuring up a case where it > would be meaningful to cache a response w/o associated headers. > Cookies are private -- managing the state of the interaction between a user and a server is their purpose in life. But the pages they are sent with do not have to be private. > For example, if this response needed Set-cookie, why wouldn't every > other use of the same response also need some Set-cookie associated > with it? Right, *some* set-cookie, but definitely not the same set-cookie. While I suspect I can write a scenario where a Set-cookie > would tag along with an arbitrary response where the resource might > be retrieved in another context w/o the need for the Set-cookie, my > sense is that this would be a non-real world fabricated situation. > You don't have to stretch too far. If you write a server application where a user who does not already have a cookie for that server is given a new cookie when they go to the home page on that server, then this situation applies. You set the home page up as cachable but stale so that it doesn't have to be re-fetched each time, just revalidated, and along with the 304 response, the server sends a set-cookie header particular to that new user. (It might have a user account number in it, for instance). --Shel
Received on Tuesday, 20 February 1996 16:33:00 UTC