Received: by taz.hyperreal.com (8.6.12/8.6.5) id KAA03942; Sun, 21 Jul 1996 10:34:25 -0700 Received: from fully.organic.com by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id KAA03936; Sun, 21 Jul 1996 10:34:23 -0700 Received: from localhost (brian@localhost) by fully.organic.com (8.6.12/8.6.12) with SMTP id RAA02569 for ; Sun, 21 Jul 1996 17:38:40 GMT X-Authentication-Warning: fully.organic.com: brian owned process doing -bs Date: Sun, 21 Jul 1996 10:38:40 -0700 (PDT) From: Brian Behlendorf To: new-httpd@hyperreal.com Subject: Re: Broken clients In-Reply-To: <199607211404.KAA00481@telebase.com.> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com strstr(agent, "Mozilla/2") && strstr(agent, "Win95") would appear to capture the right combination, sparing MSIE, maybe? A more general solution: Alexei has hacked up for Organic a module which sets environment variables (for use by CGI scripts, PHP, SSI's, whatever) based on a regex match against the User-Agent header, i.e. BrowserMatch /Mozilla\/2/ plugins javascript or whatever. Right now it's like a switch statement - the first match is the only one which can set env vars, so that if we need to have 30 different Browser lines we're not going through each regex test with each web hit. However, we could also probably throw in a different directive which was processed on each hit, i.e. BrowserMatchAny /Mozilla\/2.*Win95/ brokenkeepalivetimeout BrowserMatchAny /Mozilla\/2/ brokenkeepaliveflushing or whatever. At this point, the keepalive code, when it makes its decision whether to use keepalives, when to flush headers, etc., tests for those environment variables. The glory is that as the environment changes, as the client marketshare changes and as new browsers come out with similar bugs, we don't have to change the code. People can tweak this to whatever combination of speed vs. functionality they desire. Obviously the speed of such a system is a critical concern, seeing as how this needs to happen right after the request is finished being received and before any response is sent. Maybe previous pattern match results can be cached in shared memory in a hash table of some sort? Brian On Sun, 21 Jul 1996, Chuck Murcko wrote: > Yes, I know it does. Problem is, we won't run keepalives here at all unless > we use this. I have observed the same problem with MSIE/Windoze95, but no > one else in the group has. > > You're the only comment on this so far. I've been running this live for > two days now without problems. > > In addition to MSIE, remember that it also disables keepalives for all the > Netscape 2 versions that work (UNIX, Mac). People here don't consider > these or MSIE a significant enough percentage of browsers in use to > worry about the performance hit to them, though. > > I'm waiting on group consensus to commit this. > > Brian Behlendorf liltingly intones: > > > > > > This also disables keep-alives for all versions of MSIE, by the way. Is > > this warranted? --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS