Loading ...
Sorry, an error occurred while loading the content.

Re: Connection filters and Keep-Alive

Expand Messages
  • Stas Bekman
    ... I first successfully implemented the tandem trick to learn that when the method is HEAD, the filter won t see the EOS bucket. Digging into the Apache
    Message 1 of 4 , Mar 1 7:56 PM
    • 0 Attachment
      Stas Bekman wrote:
      > Stas Bekman wrote:
      >> Mathias Herberts wrote:
      >>> Hi,
      >>> still in the process of building an Input Connection Filter I noticed
      >>> something wrong with all Connection Filter examples I could find
      >>> (including HTTPHeadersFixup), in case the connection is instructed to
      >>> be kept open with 'Connection: Keep-Alive', several requests will be
      >>> run through the same instance of the filter, therefore it is not
      >>> possible to safely ignore the possible body of a POST (or DAV)
      >>> request. One must keep track of Content-Length and only ignore body
      >>> if 'Connection: close' was issued (as per RFC 2616).
      >>> Anybody else aware of that?
      >> Not me. I'm still learning the topic ;) Thanks for the heads up,
      >> Mathias. I have never tried with 'Connection: Keep-Alive', though I
      >> think there must be a better way to tell separate requests from each
      >> other. I'll investigate this and get followup on this.
      > The net thrown in the httpd-dev sea came back empty. The fish is hiding
      > behind the rocks, scratching their private itches.
      > It seems that Apache provides no way to tell one request over another
      > when Keep-Alive is in effect. I need to look at the ap_discard_body
      > function, since somehow it knows when there is no more body to read.
      > Meanwhile I have the following filter tandem idea that may do the trick.
      > We could add a connection response filter, whose only purpose will be to
      > set a note in the connection object when it sees the response headers (I
      > don't think EOS is sent in the response stream) flagging the incoming
      > filter mate that the next time it's invoked it'll be a new request. That
      > will only work if after sending the headers, it's known that the
      > request body is fully consumed. I think that's the case, but I'm not
      > 100% sure.

      I first successfully implemented the tandem trick to learn that when the
      method is HEAD, the filter won't see the EOS bucket.

      Digging into the Apache source I've found a much simpler way to handle the
      context reset, using $c->keepalives counter, which I've exposed recently (i.e.
      you need the current cvs or wait till 1.99_13 is released).

      That technique is documented at:

      I've just uploaded a new version of
      Apache-Filter-HTTPHeadersFixup-0.02_01.tar.gz on CPAN, which now uses that
      technique to handle keepalive connections.

      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
      mailto:stas@... http://use.perl.org http://apacheweek.com
      http://modperlbook.org http://apache.org http://ticketmaster.com

      Report problems: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
      List etiquette: http://perl.apache.org/maillist/email-etiquette.html
    Your message has been successfully submitted and would be delivered to recipients shortly.