On 2010-09-20 02:37, Aryeh Gregor wrote:
2010/9/19 Julian Reschke<[email protected]>:
So it's a workaround that causes a performance optimization. It wouldn't be
necessary if the linked resource would have the right caching information in
the first place.
Sure it would. You can currently only save an HTTP request if a
future Expires header (or equivalent) can be sent. A lot of the time,
the resource might change at any moment, so you can't send such a
header. The client has to check every time, and get a 204, even if
the resource changes very rarely. If you could indicate in the HTML
source that you know the resource hasn't changed, you could save a lot
of round-trips on a page that links to many resources.
Describing it that way sounds odd, as that would be explicitly
indicating which resources are "still" valid,
imagine the bloat if the document links to hundreds of others.
It would be better to define this as explicitly indicating which
resources are NOT valid any longer,
with most sites/web applications this would only be a select few links.
I like the idea though as it'll allow a page to tell the browser that
"Oh BTW! If you happen to have this link cached, it was last updated on
...... You might wanna re-check that if you got a older copy, despite
what the cache copy's expire is."
Some thought need to be given to this though. This will only be same
domain right? If not then it could be partly used for a DoS. (if a
popular site is compromised and changed to link to a ridiculous amount
files on other sites it could get nasty right?)
--
Roger "Rescator" Hågensen.
Freelancer - http://EmSai.net/
