httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Dean Gaudet)
Subject Re: AOL == problem
Date Fri, 20 Dec 1996 00:30:19 GMT
AOL's caches have never behaved properly.  They don't respect anything
that resembles expiration.  They cache negotiated pages which don't
have Last-Modified: headers.  As far as we can tell their caches are
hardwired to 24 hour expires.  Of course I haven't investigated any of
this in over a year, so I'd be delighted to be told differently.

Why is it that once a company passes a certain size they don't seem to be
able to read standards?  Consider Compuserve and SMTP/MX.  Microsoft and
PPP, DHCP, ip fragmentation.  Netscape and DNS (navigator caches all
responses forever, doesn't use more than a single A record even if
multiple are present).

Of course small companies are just as ignorant, but usually easier to find
the person to fix the problem.


In article <>,
Randy Terbush  <> wrote:
>Actually, I have found some other info after signing up for AOL this morn...
>The proxies seem to be caching the error message for the failed URL 
>indefinitely. I was finding that requests for a page through their
>browser _never_ hit our server. If I requested the same document without
>.html, it would successfully retrieve it. Proof? The only difference
>now is that the server is sending HTTP/1.0 to the proxy for AOL.
>I've been playing expiry games through the day, and have gotten most
>of this customers content accessible again. However some pages appear
>> Running 1.2-dev on 2 machines.
>> One sends Etag, one doesn't. The one that does triggers the AOL message.
>> Randy Terbush liltingly intones:
>> > 
>> > Hmmm. As I dug into this, I wondered about Etag:. 
>> > 
>> > I'll go upgrade a 1.1.1 server now.... :)
>> > 
>> chuck
>> Chuck Murcko	N2K Inc.	Wayne PA
>> And now, on a lighter note:
>> The light at the end of the tunnel may be an oncoming dragon.

View raw message