You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Brian Eaton <be...@google.com> on 2009/02/05 03:17:45 UTC
gadget rendering cache headers
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.
Re: gadget rendering cache headers
Posted by Brian Eaton <be...@google.com>.
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 <ie...@tfd.co.uk> 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 <ie...@tfd.co.uk> 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.
>>>>
>>>
>>>
>
>
Re: gadget rendering cache headers
Posted by Ian Boston <ie...@tfd.co.uk>.
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 <ie...@tfd.co.uk> 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.
>>>
>>
>>
Re: gadget rendering cache headers
Posted by Brian Eaton <be...@google.com>.
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 <ie...@tfd.co.uk> 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.
> >
>
>
Re: gadget rendering cache headers
Posted by Ian Boston <ie...@tfd.co.uk>.
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.