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

[Tobias Anton]

On Tuesday 27 August 2002 20:45, Waldo Bastian wrote:
> On Tuesday 27 August 2002 08:36 am, Tobias Anton wrote:
> > 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.
>
> So if a page sets a timeout of 2 seconds that is basically ignored for the
> images then because the expire date reported by http will very likely be
> larger than that. Which makes me wonder why you propagate expire times at
> all then.

Hmm, you're right. I assumed that metadata["expire-date"] was not sent at all 
if no "Expires" header had been received before. And I tested with a page 
that uses 900 as relative expire timeout (http://www.heise.de), so this 
effect didn't show up here.

I think the http cache behaviour should be changed in the following way:

An expire date should only be set in the response metadata if it was 
explicitly set by a response from the web server (or, in case of a cached 
read by a call to http_update_cache)
If not, the line with the expire date in the cache entry file should be left 
blank to indicate that no expire date has been specified.
Internally, kio could use the default expire date if it finds the expire date 
line to be empty.

Should be a piece of cake actually, but do you second that?

> ====
>
> Can you explain this change in your patch:
> -    return (difftime(now, m_expireDate) >= 0);
> +    return (difftime(getAbsoluteExpireDate(), now) >= 0);
The previous check was wrong IMO:

man difftime (SuSE Linux 7.3) says:
"
double difftime(time_t time1, time_t time0);

DESCRIPTION
       The difftime() function returns the number of seconds
       elapsed between time time1 and time time0, ...
"

So the new statement reads:
"the object is expired if a positive number of seconds has elapsed between the 
expire date and now."

That sounds correct to me, no?

====

>
> On Tuesday 27 August 2002 08:36 am, you write:
> > 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.
>
> But on Monday 26 August 2002 07:36 am, you wrote:
> > > I think that's wrong and I think the images should expire on
> > > t_doc_create+t_doc_expire.
> >
> > Imagine a cached image that is referenced from all pages of a web site
> > and all pages have a relative expire date.
> >
> > Browsing around will lead to strange results there, i.e. as long as no
> > page is visited twice and the time between two page views is less than
> > the (relative) expire time, such an image will never be reloaded.
>
> So yesterday you say "using t_doc_create is bad because the images will
> never be reloaded" and today you say "using t_img_create is good because
> the images will never be reloaded".

I didn't say that. I meant that images could be reloaded because they're 
expired although they are part of a page that
- is not yet expired,
- was responsible for setting their relative expire date.

Imagine the following situation:
- a page is loaded at t0 with a relative expire date of 51 seconds.
- then, images contained in this page are loaded at t0+10.
  their expire date is set to t0+51.
  (with t_img_create, they'd be set to t0+61)

- the page is loaded again, at t0+50, and thus is taken from cache.
- images in that page are loaded again at t0+51 or even later.
  Now they are expired and reloaded from the internet. Bummer.
  (with t_img_create, their cache entries would still be valid)

With expire date calculation based on t_img_create, this wouldn't happen. 
Though, images would be reloaded as soon as the request is scheduled after 
t0+60, which is fully sufficient.

I admit that this is a timing coincidence that occurs not too often, but I 
still see no disadvantage fronting that.

Additionally, updating relative expire dates on existing cache entries is 
possible with t_img_create, and it's not with t_doc_create, but here I'm 
about to repeat myself.

Tobias