httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: [PATCH] dechunking, body filtering
Date Sat, 14 Oct 2000 15:11:24 GMT
Oops...  A few hours ago I mistakenly responded to Ryan directly
instead of to the list, and I didn't have gnus set up to archive
outgoing messages :(  I'll attempt to reconstruct my comments to Ryan
(and hopefully prove that gnus is now configured in a reasonable
way)...  I'm sorry if this leads to confusion if Ryan responds to my
orginal note...  

rbb@covalent.net writes:

> > Data structure changes
> > 
> >   http_filter's ctx:
> > 
> >     Add remaining field.  ap_setup_client_block() and dechunk_filter() know how
to
> >     find this ctx and set this field.
> 
> You can't do this.  You can't even garauntee that http_filter will be in
> the server.  I have every intention of writing an input filter that takes

> ftp requests and converts them to http.  When I do that, there will be no
> http_filter in the request, and this will break.  No filter can EVER
> depend on another filter being in the stack.

So put your ftp->http converter filter *below* HTTP_IN.

If Apache's http infrastructure is being used then it needs to know
that HTTP_IN is there.  HTTP_IN is just a cog in the HTTP support
provided by Apache, interdependent with other parts.  We don't let
modules replace just any part of Apache's HTTP support.  It is o.k. to
have some interdependent pieces which can't be replaced individually.

An example of another case where we'll want to know the state of
HTTP_IN *outside* of HTTP_IN:

In some response buffering logic, we'll want to know if we've received
a pipelined request yet.  If so, we won't flush to the network...  If
not, we'll flush to the network.

How will we know if another request has arrived without querying the
state of HTTP_IN, since if the request arrived HTTP_IN hid the
knowledge of it from the filters above?

> >   r
> >  
> >     Add "void *filtered_input" field; ap_get_client_block() holds onto 
> >     leftover body in this field.  Ugly that we clutter the r...  Ugly that
> >     I made it "void *" instead of "ap_bucket_brigade *" (avoids an additional
> >     #include in "httpd.h" for (probably) no good reason).
> 
> This was discussed yesterday and people really disliked it.  If filters
> are told the maximum amount of data they can return, this is
> unnecessary.

Some people disliked it; some people didn't ;)  I don't have any
problem at all with ap_get_client_block() saving state information
between invocations.  I agree that directly in the r isn't a nice
place, but we can perhaps find a better place rather than imposing the
length parameter.  What about r->notes?  (If there is no other place,
I find putting it in the r preferable to using the length parameters.) 

Some issues with the length parameter(s):

. HTTP_IN deals with byte counts on unfiltered input...
  ap_get_client_block() deals with byte counts on filtered input...
  How does the discrepancy get resolved?

. what if a filter below ap_get_client_block() wants to return a pipe
  bucket because the request body was filtered on the other side of a
  pipe?  how do we govern the length there?

. I don't see the length parameter(s) as being helpful overall to most
  filters... sure, the filter gets the opportunity to place
  restrictions on the filter below it, possibly simplifying some
  logic, but on the other hand, the filter has to satisfy the
  restrictions of the filter (or ap_get_client_block() or whatever)
  above it...  we just move the problem somewhere else...
  
  it seems less error prone and simpler to let filters deliver data as
  they see fit (like output filters); this length checking is extra
  code in every input filter; I'm sure it isn't rocket science, but I
  don't see the benefit

If the patch is bad because

. HTTP support in one place in Apache (ap_get_client_block()) has to
  be aware of HTTP support in another place in Apache (HTTP_IN)

. ap_get_client_block() has to save state between invocations

then I can live with that :)

Thanks for your comments,
-- 
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