[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl-cvs
Subject:    cvs commit: modperl-2.0/t/filter/TestFilter in_str_consume.pm
From:       stas () apache ! org
Date:       2003-09-23 22:45:01
[Download RAW message or body]

stas        2003/09/23 15:45:01

  Modified:    t/filter/TestFilter in_str_consume.pm
  Log:
  updates on the partial input body consume story
  
  Revision  Changes    Path
  1.11      +17 -0     modperl-2.0/t/filter/TestFilter/in_str_consume.pm
  
  Index: in_str_consume.pm
  ===================================================================
  RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/in_str_consume.pm,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -u -r1.10 -r1.11
  --- in_str_consume.pm	23 Sep 2003 02:21:40 -0000	1.10
  +++ in_str_consume.pm	23 Sep 2003 22:45:01 -0000	1.11
  @@ -16,6 +16,21 @@
   # the snooping debug filter). Of course if the filter returns
   # Apache::DECLINED the unconsumed data will be passed to upstream filter
   #
  +# However this filter has a problem. Since it doesn't consume all the
  +# data, the client is left with un-read data, and when the response is
  +# sent a client get the broken pipe on the socket. It seems that LWP
  +# on linux handles that situation gracefully, but not on win32, where
  +# it silently dies. Other clients may have similar problems as
  +# well. The proper solution is to consume all the data till EOS and
  +# just drop it on the floor if it's unneeded. Unfortunately we waste
  +# the resources of passing the data through all filters in the chain
  +# and doing a wasteful work, but currently there is no way to tell the
  +# in_core network filter to discard all the data without passing it
  +# upstream. Notice that in this test we solve the problem in a
  +# different manner, we simply call $r->discard_request_body which does
  +# the trick. However it's inappropriate for a stand-alone filter, who
  +# should read all the data in instead.
  +#
   # this test receives about 10 bbs
   # it reads only the first 23 bytes of each bb and discards the rest
   # since it wants only 105 bytes it partially consumes only the first 5 bbs
  @@ -79,6 +94,8 @@
       unless ($wanted_total) {
           # we don't want to read the rest if there is anything left
           $filter->seen_eos(1);
  +        # but we really should, though we workaround it in the
  +        # response handler, by calling $r->discard_request_body
       }
   
       if ($filter->seen_eos) {
  
  
  
[prev in list] [next in list] [prev in thread] [next in thread]