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

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 28 August 2002 08:07 am, Tobias Anton wrote:
> 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?

kio-http calculates the expire time if none was explicitly given. I don't want 
the application (khtml in this case) to do this, in fact, the application 
might not have the necassery information to do so. Some sort of flag to 
indicate that the expire time may not be changed could be an option though.

> > ====
> >
> > 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?

Yes, it sounds correct, but it isn't.

Try the following code:
  time_t now = time(0);
  time_t exp_time = now+10;
  printf("Diff = %f", difftime(exp_time, now));

exp_time is 10 seconds in the future (not yet expired), but the result is 
positive.

> 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.

I don't see a need to store relative expire dates. A relative expire date can 
be converrted to absolute and from then on the absolute date can be used 
everywhere. The current code does that.

Cheers,
Waldo
- -- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9bRAON4pvrENfboIRAlhFAJ46GVBbZ5yskFOjOrzh4jxZpyq0cgCgnI7z
LGihnYxpqd2h2wCfHY9DxBY=
=gCco
-----END PGP SIGNATURE-----