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 wrote:
> Yes private elimin
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 bou
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 wrote:
> I think there are 2
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 suf
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
5 matches
Mail list logo
