Re: FW: cvs commit: apache-2.0/src/main http_core.c http_protocol.chttp_request.c

[Jeff Trawick <tr...@bellsouth.net>]

rbb@covalent.net writes:

> > What if installing core_filter is associated with initializing the
> > conn_rec structure (perhaps in a hook called right after creating the
> > conn_rec)...  
> > 
> > . conn_rec needs an output filter list
> > . when the request_rec is initialized for a new request it starts off
> >   with the chain on the conn_rec
> > . ap_add_filter() (which needs to be renamed to ap_add_output_filter()
> >   anyway) would need to take the address of the list head
> >   (&c->output_filters or &r->output_filters) to be modified
> > 
> > What am I missing here?
> 
> Nothing.  I actually just had this conversation and was about to post
> about it.  I would modify a few things though.
> 
> 1)  Remove the output filters from the request_rec.  They may be request
> oriented, but we only support one request at a time.

See below...

> 2)  When adding a filter, we provide a request_rec and a conn_rec.  Any
> filter that does not have a request_rec is automatically connection
> oriented.

Cool...  I forgot that ap_add_filter() needs the r (if applicable) so
that it can set f->r.

> 3)  At the end of a request, clear all filters from the conn_rec, except
> the connection oriented ones.

What about subrequests?  Hanging the filter list off of the r works
very nicely for subrequests.  Having one filter list hanging off the c
means that at the end of a subrequest we have another cleanup
operation.  What about redirects?  There is another cleanup operation. 

What does having separate lists hurt?  Saving a pointer in the r?  In
return we save code (and pathlength).

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Re: FW: cvs commit: apache-2.0/src/main http_core.c http_protocol.chttp_request.c

[Greg Stein <gs...@lyra.org>]

On Wed, Oct 04, 2000 at 11:30:57AM -0700, rbb@covalent.net wrote:
>...
> Today, I will code connection oriented filters go in conn_rec, request
> oriented filters go in the request_rec.  If this falls down for some
> reason, we'll try putting everything in the conn_rec.

+1

I believe that you will want to keep them separated. Consider the semantics:
certain filters are associated with the connection, others with the request
itself (content filters), and yet others with a subrequest. Each can have a
chain, and they would be initialized with the "next level's" output filters.

For example:

    new_request:
    
      r->output_filters = conn->output_filters;
      
    new_subreq:
    
      subreq->output_filters = mainreq->output_filters;

When the filter->r changes from a subreq to a req, or from a req to NULL
(meaning the connection), then we see the boundaries quite easily. Note that
ap_add_filter() already deals with the boundaries properly and will not add
a filter past the "current" block of filters. Therefore, adding a filter to
a subreq ensures it will go before the request and the conn filters. Adding
a filter to "r" will always end up before the conn filters (f->r == NULL).

There is no monkeying with pools or removing filters in this approach. Each
item (subreq, req, or conn) simply points into its proper place in the
chain. Yes, we alloc filter_req from a pool associated with the (sub)req or
conn:

SUB         REQ        CONN
  \           \           \
   S1 -> S2 -> R1 -> R2 -> C1 -> C2

It feels quite straight-forward and quite easy. I look forward to your impl!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: FW: cvs commit: apache-2.0/src/main http_core.c http_protocol.chttp_request.c

[rb...@covalent.net]

> > 3)  At the end of a request, clear all filters from the conn_rec, except
> > the connection oriented ones.
> 
> What about subrequests?  Hanging the filter list off of the r works
> very nicely for subrequests.  Having one filter list hanging off the c
> means that at the end of a subrequest we have another cleanup
> operation.  What about redirects?  There is another cleanup operation. 
> 
> What does having separate lists hurt?  Saving a pointer in the r?  In
> return we save code (and pathlength).

The separate list hurts because it ties the filters to a request based
protocol.  I was hoping to make the filtering more generic so that other
protocol modules could work with it too.  Hmmm.....  I hadn't thought of
subrequests and redirects.  Is this actually working now?  We don't
currently have a way to remove a filter from the filter list, so if a
sub-request adds a filter, doesn't it stay on the filter list past the end
of the sub-request?  I don't know, I haven't checked recently.  Oh, I see
the sub-request's filters stay in the sub-request request_rec.  So the
original request doesn't have access to it.  

It seems to me, that when we add a filter, we automatically give it a
pool, either in the request_rec or conn_rec.  We need a remove_filter
function regardless, could we register a cleanup with the correct pool,
so that when a sub-request goes away, it automatically removes any filters
it has added?

This is coming off the top of my head, but I kind of like that design, and
I think it will work.  Plus, something (I don't know what) really bothers
me about separating the filters between connection and request recs.  I am
not even close to standing in the way of doing it, but it grates on me.  I
am perfectly willing to code either method today, just to see how they
work.  Let's do that in fact:

Today, I will code connection oriented filters go in conn_rec, request
oriented filters go in the request_rec.  If this falls down for some
reason, we'll try putting everything in the conn_rec.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------