caching-patch V0.2.1 (Was: Re: caching-patch V0.2.0)

[Tobias Anton]

On Monday 26 August 2002 22:26, Waldo Bastian wrote:
> I find the fact that the expiration date of the document sets 
> the expiration date of the images a hack in and of itself.
> If you want to set the expiration date of an image you should
> do that by sending the correct expiration date in the http headers 
> of that image.
If I was a web server, i'd do that.
If I was a web developer, i'd make the web server do that.

But I am not, and because there are many web developers who 
- don't give a damn about the caching behaviour,
- expect their browser to propagate the expire dates,
- don't have any idea how to affect the http headers of their pages,
I've made this patch.

I finally want my browser to keep network traffic low, and with that patch, we 
can get nearer to that.

If you read it carefully, you'd notice that the patch will not cause an expire 
date be lowered by KHTML. Only raising the page's expire timeout takes place. 
Only if necessary and only if possible.

This is the best behaviour for pages whose images lack an expire date at all. 

And manymany images on web servers are transferred without expire dates.
I don't like to see that either, but that's the way it is. The HTML pages 
often contain an expire tag, but the images nearly always get the default 
expire date, because web developers don't even know how to affect the expire 
date.

> But to come back to your problem, isn't that then simply a matter of not
> updating the expiration date of an image when it already has a prevous
> expiration date set?

That would work for lots of cases, but not for all.

I still think that
t_img_expire = t_img_create + t_doc_expire
makes more sense:

Given a page and its images are not cached, the images are loaded seconds 
after the page, so that t_img_create will only be a bit larger than 
t_doc_create.
This is good for the caching functionality, because if a page is loaded again 
(but from cache) shortly before its expire date is reached, the images in 
that page are less likely to be reloaded because they are expired in between.

Also, think of a page that has javascript code loading images on demand. If a 
page is loaded, stands there for a while, and then the user's action causes 
the image to be loaded, the expire date for that image would be set to a time 
the past.

Another thing I'd like to achieve is that the expire date can be updated via 
DOM. Adding two or three more lines of code would make it possible to update 
the expire date of a page and all of its contained objects by setting the 
"CONTENT" attribute of the http-equiv-meta-tag to another value.


In any case, the fundamental change of my patch, storing the cache-creation 
date and the http expire date in the cached objects, is necessary for each of 
these points.

So if there are no severe objections against the patch besides that you don't 
like the idea behind it, I'd really like to commit it without you reverting 
it directly in turn. Niether is it wrong nor does it crash nor does it 
intrusively affect the http cache. It only raises some expire dates if 
appropriate. I admit that it's a workaround, but it's a necessary one. Not at 
all is it a hack.

Apropos workaround:
You can hardly argument against my improvement approach by telling me to send 
the correct expiration dates in the http headers. It's not me who fails to 
send correct http headers, I'm just trying to work around that, and, let me 
repeat that, in a sensible manner. 
We had that before - we can't convince all the web developers in the world, we 
need to cope with their faulty web pages.

Tobias