httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@n2k.com>
Subject Re: AOL, BrowserMatch, allow/deny
Date Mon, 23 Dec 1996 22:19:28 GMT
Ed Korthof liltingly intones:
> 
> Without an extra API, there aren't any elegant ways I can see to fix the AOL
> problem, but we have at least three patches floating around.  It sounds like
> the consensus is that no one really wants to add the API right now, so IMO, we
> should put one or two patches in the patches directory, describe them and
> explain how to implement them, and let it go at that.  Maybe AOL will fix their
> software soon, maybe not...
> 
> Anyway, here's my patch, adapted to break AOL's proxies if AOL_DIE_DIE_DIE is
> set.  However, I would add that the cache-busting mechanism is not, so far as I
> know, the issue; if AOL hadn't cached it's failures, then that would help, but
> since they're already cached, telling AOL not to cache new things isn't going
> to do any good -- you'll still have to wait till their old cache expires.  This

Am I missing something here? Surely AOL doesn't cache multiple copies of the
same response (except on separate proxy machines, perhaps), and they *should*
be checking the origin server to see if the response has been updated before
replying with the cached copy, no?

Our testing showed we could get to our sites immediately from AOL after the
patch was applied, from accounts that were only getting the error message
before that.

> patch requires only recompilation, and allows both authentication and ordinary
> operation:
> 

Looks OK here. +1.

chuck
Chuck Murcko	N2K Inc.	Wayne PA	chuck@telebase.com
And now, on a lighter note:
Food for thought is no substitute for the real thing.
		-- Walt Kelly, "Putluck Pogo"

Mime
View raw message