RE: Squid and the Year 2000

Hi,
I dont know if this is of any help but have a look at:
http://squid.nlanr.net/Squid/1.1/1.1.21/ChangeLog
especially:
Changes to squid-1.1.20 (January 9, 1998):
        - Changed default 'average_object_size' to 13 KB.
        - Changed number of allocated file numbers to twice the number estimated.
        - Changed file_map_allocate() to not coredump when the filemap
          list becomes full. Instead, a warning is logged and new
          objects will not be saved until some swap files become available.
        - Year-2000 fixes (Arjan de Vet).

Trevor Van Der Linden
Technical Manager
BOLDWeb

> -----Original Message-----
> From: Julian Anderson [mailto:Julian.Anderson@MCS.VUW.AC.NZ]
> Sent: Saturday, 28 March 1998 16:56
> To: squid-users@nlanr.net
> Subject: Squid and the Year 2000
>
>
> Our IT group has recently been catching up on it's buzzword quota
> and attempting to determine which mission-critical network infra-
> structure elements are Year 2000 compliant, and for those that aren't,
> who to point the figure at. Hard questions have been asked about
> Squid, mainly because there is no-one to point the finger at if it
> does break, so said finger has been pointed at me.
>
> Has anyone taken a good, serious look at Squid for Y2K compliance? My
> first thought is that Squid is probably pretty safe, as most (all?) of
> it's internal dates are handled as "time_t"s or "struct tm"s, so the
> main place it could get into strife is with dates handed to it by
> browsers and servers. Unfortunately, our Y2K auditors frown at
> phrases like "probably pretty safe".
>
> Now of course we all know how closely browser and server implementors
> follow the specs, right? So I took a look at the relevant RFCs. RFC
> 1945 (HTTP/1.0) and RFC 2068 (HTTP/1.1) both allow the same three
> formats:
> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
> Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
> Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
>
> A quick perusal of lib/rfc1123.c (from the 1.2beta11 source I happened
> to have lying around) suggests that squid probably screw up if handed
> a bogus RFC 850 date such as
> Saturday, 01-Jan-100 08:49:37 GMT
> because it depends on positional referencing into the array, and it
> assumes that years are two digits. It will cope with
> Saturday, 01-Jan-00 08:49:37 GMT
> but will then start making some incorrect assumptions about expiry
> time, etc. This won't make squid fail, just be perhaps a little less
> efficient as it may muck up IMS computations and pseudo-expiry-time
> generation.
>
> rfc1123.c does the Right Thing in generating Common Log Format entries
> and other date headers (it uses strict RFC1123 4-digit date format for
> that), assuming your OS strftime behaves correctly.
>
> Of course, if your OS is broken all bets are off. In that case,
> however, there often is someone you can point the proverbial finger
> at.
>
> Does anyone else have any suggestions about other places to look for
> potential problems? I haven't examined the cachemgr, dnsserver,
> client, unlinkd or ftpget source, nor have I checked if the
> "acl time" day-abbrevs code correctly handles Y2K leap-years.
> However, I don't use "acl time", so I don't care :-).
>
> Does anyone *know* of any other problems, or have had to make the case
> for Squid Y2K compliance to their bosses and would like to share their
> report?
>
> I don't think it's worth investigating 1.1 or 1.0 for compliance; by
> the time problems would have struck you should have upgraded to
> something newer.
>
> Comments, anyone?
>
> Jules Anderson
>
>
Received on Sat Mar 28 1998 - 14:57:14 MST