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 17:59:00 GMT
rbb@covalent.net writes:

> On 5 Oct 2000 trawick@locus.apache.org wrote:
> 
> > trawick     00/10/05 09:55:18
> > 
> >   Modified:    src/include http_core.h httpd.h util_filter.h
> >                src/main http_connection.c http_core.c http_protocol.c
> >                         http_request.c util_filter.c
> >   Log:
> >   Add a bit of infrastructure which will be needed for input filtering:
> >   
> >   1) separate filter lists hanging off the r and the c
> >   
> >      requests start off with the same filter list as the connection
> >   
> >      the input filter list is not initialized for subrequests
> >   
> >      internal redirects start off with the same filter list as the
> >      connection
> 
> 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?

>       If you are thinking of the request body, that won't work.  Most
> browsers send the request body in the same packet as the request headers,
> so the body will actually be stored in the conn_rec's bucket_brigade, and
> the body will never get to go through the input_filters that were added
> after reading the request.

What about the request body (and maybe even the header of the next
request) in the same buffer read by CORE_IN (or SSL)?

  It doesn't matter that the request body is in the same packet as the
  request headers.  CORE_IN and getline() have to work together so that
  any data after the header is made available to CORE_IN for the next
  time it is called.

  getline() is called repeatably to grab the request line and header
  fields.  It only cares about the conn_rec filters.  When it gets to
  the end of the header any unparsed data must be chained back on the
  conn_rec for CORE_IN (or SSL) to access again.

If/when ap_get_client_block is called by a handler...

  call ap_get_brigade(r->input_filters) instead of ap_bread()

  If no request-specific filters were added, r->input_filters is
  CORE_IN.

  If request-specific filters were added, r->input_filters is a not
  CORE_IN, but eventually CORE_IN will be called to deliver data from
  the client (possibly already read and stored by getline() or
  CORE_IN in the conn_rec).

What about the end of the request body?

  The end of the request body is signaled by one of three things
  (AFAIK :) ):

  a) end of connection
  b) client provided Content-Length field in header and we've seen
     that many bytes
  c) chunked encoding was used and we've hit the trailing chunk header

  Somehow the request body filters need to get EOS (or equivalent)
  when one of these happens.

  Case a) is pretty simple...

  Case b)...  Theoretically, the CORE_IN filter could take care of
  this (know the content-length and how many bytes had been delivered
  so far), but CORE_IN doesn't know anything about the r and isn't
  supposed to know such details.  If we have content-length in the
  header, we can throw in a filter between the request body filters
  and CORE_IN to insert EOS at the right point and make any extra data
  returned by CORE_IN available to CORE_IN on the next pass.

  Case c)...  The CHUNK_IN filter needs to return eos at the right
  point (not hard), and make any extra data returned to it available
  to CORE_IN on the next pass.

> The more I look at our current filtering scheme, the more it looks like
> input filters are only valid if they are added before the request is read
> from the network.

Why is that true of content filters?  
-- 
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