httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: FW: cvs commit: apache-2.0/src/main http_core.c http_protocol.chttp_request.c
Date Wed, 04 Oct 2000 18:53:59 GMT
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/

Mime
View raw message