Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 97825 invoked by uid 500); 15 Sep 2000 18:02:24 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 97808 invoked from network); 15 Sep 2000 18:02:19 -0000 Sender: greg@raleigh.ibm.com Message-ID: <39C263A6.7CC73DE7@raleigh.ibm.com> Date: Fri, 15 Sep 2000 14:00:06 -0400 From: Greg Ames X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14-15mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.cutil_filter.c References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N rbb@covalent.net wrote: > > > Is anybody opposed to extending what Ryan committed with something > > like the following? > > > > AddOutputFilter INCLUDES \ > > BUCKETTRACE(--format text --per-line 80) \ > > XLATEOUT \ > > BUCKETTRACE(--format hex --per-line 32) > > Yes, I am. This puts way too much in one directive. This can be solved > by having the module that implements BUCKETTRACE also have it's own > directive. > > I am thinking something like: > > AddOutputFilter INCLUDES BUCKETTRACE XLATEOUT BUCKETTRACE > > BucketTraceSetup call1 --format text --per-line 80 > BucketTraceSetup call2 --format hex --per-line 32 > This is not as easy for the admin as the syntax Jeff proposed. (More lines to code which must be in sync && more directives) == more rope for the admin to hang him/herself with. > With some very simple module magic, you can easily associate the Setup > with the call to the BucketTrace filter. This puts the onus on the module > implementor to allow setup for their module. > Either way, the onus would be on the module implementor. > > The string inside parens would be stored as-is (raw) in f->params. If > > no string was specified, f->params would be NULL. > > AddOuputFilter should be very simple, not trying to do too much. Agreed. > What > happens if a filter doesn't implement any arguments? It doesn't register a hook to parse arguments. > Does the core still > try to pass those arguments to the filter? No, it can't - no hook. If the core sees that there are arguments and no hook to parse them, it should complain about the AddOutputFilter statement. > The core can't determine if > the filter takes arguments, so we can't return any kind of error to the > user. A module/filter lets the core know that it can handle arguments by registering a hook to parse the filter arguments. The core should complain if there are arguments but no hook registered. The module/filter should complain if it doesn't like its arguments. Greg