Re: negative ttl in squid-1.0.15

alex@icl.kazan.su writes:

>Hi!
>
>As I can get from squid source, ttl shouldn't be negative
>
>>ttl.c:226
>> if (expire > -1) {
>> ttl = (expire - squid_curtime);
>> if (ttl < 0)
>> ttl = 0;
>> debug(22, 4, "ttlSet: [%c%c%c%c%c%c%c] %6.2lf days %s\n",
>> flags & TTL_EXPIRES ? 'E' : '.',
>
>but when I'm getting http://altavista.digital.com/ (BTW, all my
>ttl problems are always concerned with altavista :) what I found
>in squid.log:
>
>[17/Sep/1996:19:30:26 +0400] ttl.c:191: ttlSet: Choosing TTL for http://altav
is
>ta.digital.com/
>[17/Sep/1996:19:30:26 +0400] ttl.c:225: ttlSet: Server-Date: Wednesday, 11-
Se
>p-96 15:39:01 GMT
>[17/Sep/1996:19:30:26 +0400] ttl.c:291: ttlSet: [.S....D] -2.99 days http://
al
>tavista.digital.com/

In this case the TTL is not being set in the code fragment above
(line 226). Its being set here:

    } else {
        /* Take deffault TTL from when the object was served */
        ttl = served_date + default_ttl - squid_curtime;
        flags |= TTL_DEFAULT;
    }

The 'D' in '[.S....D]' means it used the default TTL.

It looks like you got the altavista page from a neighbor or
parent who is using larger TTLs than you are.

This is a shortcoming in both HTTP/1.0 and ICP. We need to be
able to specify a maximum age we are willing to accept in
the request. HTTP/1.1 has this already I believe.

Duane W.
Received on Tue Sep 17 1996 - 09:20:50 MDT