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.
