- From: Roger Hågensen <rescator@emsai.net>
- Date: Mon, 20 Sep 2010 07:40:48 +0200
On 2010-09-20 02:37, Aryeh Gregor wrote: > 2010/9/19 Julian Reschke<julian.reschke at gmx.de>: >> 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/
Received on Sunday, 19 September 2010 22:40:48 UTC