Date: Sat, 30 Aug 1997 15:07:57 -0700 (PDT)
From: Ed Korthof <ed@organic.com>
To: new-httpd@apache.org
Subject: Re: filter API spec
In-Reply-To: <3407345A.2BBF5E95@algroup.co.uk>
Message-ID: <Pine.GSO.3.95.970830122958.11454B-100000@eat.organic.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Fri, 29 Aug 1997, Ben Laurie wrote:
> Alexei Kosut wrote:
> > > > SSL is the first item on the stack, it would be in the right order. It
> > > > would probably get tacked on in the new connection_open API phase, before
> > > > anything else, unless you had other transport-layer filters as
> > > > well that activates (i.e. if you had SSL and HTTP-NG filter modules,
> > > > you'd have to make sure they were in the right order.)
> > >
> > > Err, yes, but how?
> > 
> > I don't see what you mean. They'd push their filters onto the
> > connection's BUFF, in the order that they get their connection_open phase
> > run. So you'd just order them the correct way when you installed the
> > modules, just like you need to put mod_rewrite after mod_proxy if you
> > want to rewrite proxying.
> > 
> > Or am I misunderstanding the question?
> 
> Probably not - but it's a rather inelegant solution. Suppose mod_proxy
> and mod_rewrite both want to push filters but in the opposite order.
> It's all rather messy, isn't it?

There are two kinds of filters; one which happens on a per-connection
level (which thus has the opportunity to radically alter the protocol
used), and one which happens on a per-request level (which thus does not
have the opportunity to modify the request line or the headers before
they're parsed or after they've been printed). 

In general, I think we should be moving towards determining sequences like
which filters are added first via the configuration files, rather than at
compile time. 

But for connection-level filters, I'm not sure this makes sense; it seems
to me that any connection level filters should have a hard-coded sequence. 

It also seems that the modules described above would fit better into a
per-request model of filtering.  With that, the AddFilter directive which
Alexei described may well solve the problem, since it provides sequence.

OTOH, maybe it makes sense to have a similar directive for <Directory>
and/or <File> sections (though this does mean additional work in merging
directives).  That would provide more sequence for request-level filters,
and allow the filters to be modified at those levels of granularity by
already existing containers.  I dunno; it might or might not be
worthwhile.

Anyway, I'd be willing to create a directive like

ConnectionFilters (In|Out) {list}
[or a list like
    ConnectionFilter (In|Out) {filter1}
    ConnectionFilter (In|Out) {filter2}
...]

which could exist on a per-virtual-host level -- but I'm not sure it would
actually be useful or benificial, and I'm going to defer to Alexei.  Is
there a case where this would be necessary for connection-level filters?

Ed, who is not as tired as when he managed to misspell Alexei's name *and*
refer to sfio as stdio <blush>

     -- Ed Korthof        |  Web Server Engineer --
     -- ed@organic.com    |  Organic Online, Inc --
     -- (415) 278-5676    |  Fax: (415) 284-6891 --