I think "cache-control: private" takes care of most of the issues about binding content to sessions. Since we have that we don't need to worry too much about intermediate caches. Interactions with the browser cache are where I'm seeing trouble.
On 2/4/09, Ian Boston <[email protected]> wrote: > I think there are 2 issues, > the 304 response and caching > 304 > if-modified-since is not sufficient where the content sent to the client > contains tokens bound to the session. (OAuth) the expiry of those tokens > will add information to the resolution of if-modified-since, but its > probably not sufficient. > > In addition the ETag should represent final content sent, ie probably a > sha-1 hash of the content stream would be appropriate (ms since epoch of > generation, which is often used, would not be good enough) > > Caching. > All content containing tokens should only be cached bound to sessions, ie > private to intermediaries and its doubtful of the value of caching in the > server, as if there are embedded tokens in the content. > > This is based on past implementations, so, I should really go and read the > gadget code again before responding. > Ian > > > On 5 Feb 2009, at 02:17, Brian Eaton wrote: > > > > Has anybody had a look at how cacheability of the container page vs > > cacheability of the gadget iframe page plays out? > > > > I'm trying to track down a bug where a gadget tries to reuse an > > expired security token because a container page returned a 304 instead > > of a 200. ETag and if-modified-since headers are relevant, so if > > somebody has already thought about those in depth please share. > > > >
