httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: cvs commit: apache-2.0/src/main http_connection.c http_core.c http_protocol.c http_request.c util_filter.c
Date Thu, 05 Oct 2000 19:40:12 GMT
rbb@covalent.net writes:

> > > Does this make sense?  How do we add input filters for a request?  We
> > > don't even have the request until after the input filters have been
> > > run.  
> > 
> > It should be o.k. to run through connection filters before we have set
> > up request filters.  That is o.k. on output (for second response)...
> > Why not on input?
> 
> All input filters are request filters.  That's what I'm trying to
> explain.  It isn't possible to add an input content filter.  At least, not
> that I can see working everytime.

I'm stuck already :(

Maybe my terminology is bad, because I have a hard time accepting that
it doesn't work (every time) to have an "input content filter."  Does
it work every time in 1.3 to have a request body and deliver it to a
handler that wants it?  If so, then it shouldn't be too hard to let a
filter play with the data in between the piece of code that knows how
to split off the request body and the handler.

Is this terminology wrong?

  request filter

    a filter which runs only within the scope of a particular request;
    it doesn't necessarily run on all requests on a connection

  input content filter

    a filter which transforms (or passes through unchanged) the
    request body (e.g., POST-ed data); an input content filter is a
    request filter

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

Mime
View raw message