Just submitted a small Shindig change that lets the container override the max-age parameter on gadget rendering responses. I think that'll be better than the five minute default we've got now, but probably still not perfect.
On Thu, Feb 5, 2009 at 1:26 PM, Ian Boston <[email protected]> wrote: > Yes private eliminates intermediaries. > Are the etags bound to the exact content of the response or to the > underlying entity. (ie the gadget content without tokens). ? > I assume that the the gadget server is emitting etags and the browser is > using etags to check for staleness. > If the etag is bound to content and the browser is using the etag, then the > gadget server should know when the tokens expire to know when the > if-modified-since should trigger a full response. > > Ian > On 5 Feb 2009, at 17:52, Brian Eaton wrote: > >> 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. >>>> >>> >>> > >
