Received: (from majordom@localhost) by hyperreal.org (8.8.5/8.8.5) id FAA01819; Tue, 29 Jul 1997 05:13:07 -0700 (PDT) Received: from DECUS.Org (Topaz.DECUS.Org [192.67.173.1]) by hyperreal.org (8.8.5/8.8.5) with ESMTP id FAA01808 for ; Tue, 29 Jul 1997 05:13:04 -0700 (PDT) Received: from Master.DECUS.Org (master.process.com) by DECUS.Org (PMDF V4.2-13 #18511) id <01ILSVW65UOW8X2DYY@DECUS.Org>; Tue, 29 Jul 1997 08:12:54 EDT Date: Tue, 29 Jul 1997 08:09:46 -0400 From: coar@decus.org (Rodent of Unusual Size) Subject: Proposal: mod_setenvif and mod_browser To: New-HTTPd@apache.org, Coar@decus.org Message-id: <97072908094654@decus.org> X-VMS-To: NH X-VMS-Cc: COAR Content-transfer-encoding: 7BIT Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org I've been looking at Paul's setenvif module, and I'd like to re-propose something that was mentioned 'way back at the beginning of the [calendar] year. BrowserMatch[NoCase] is a special case of what mod_setenvif does (set envariables based upon header-field values). I would like to see mod_browser replaced with mod_setenvif, and the "BrowserMatch*" directives added to setenvif as special cases for compatibility's sake. I've done some fiddling with mod_setenvif to make it use RAW_ARGS rather than a new ITERATE3 argument type, and added a UnSetEnvIfZero flag directive to control whether "banned=0" means banned has a value or is un-defined. (I agree with Paul that the current treatment of zero as true is a little ambiguous.) Comments? I think being able to set envariables based upon *any* of the header-fields would be a big win. #ken :-)}