You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-cvs@httpd.apache.org by jo...@apache.org on 2003/09/29 21:20:04 UTC

cvs commit: httpd-apreq-2 STATUS

joes        2003/09/29 12:20:04

  Modified:    .        STATUS
  Log:
  I intend to mess with mod_apreq.c to ensure internal redirects work.  The input filter chain may get clobbered on internal redirects and subrequests, which can lose whatever POST data lies in mod_apreq's spool brigade.
  
  Revision  Changes    Path
  1.22      +14 -4     httpd-apreq-2/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/httpd-apreq-2/STATUS,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- STATUS	19 Aug 2003 17:00:01 -0000	1.21
  +++ STATUS	29 Sep 2003 19:20:04 -0000	1.22
  @@ -30,9 +30,19 @@
         ./configure and abort if not satisfied.
   
       - Write tests to exercise the filter prefetch code:
  -         Output filter w/ a streaming content-handler,
  -         that needs apreq to read POST data that is beyond 
  -         what the content handler has already pulled in.
  +        We need to make the prefectch code compatible
  +        with internal redirects and subrequests.  Also
  +        should stop parsing at filter_init() stage if 
  +        the only handler that needs libapreq is a 
  +        pre-content handler.  I think we'll wind up needing
  +        to adjust r->proto_input_filters, making it
  +        point at the apreq filter (right behind HTTP_IN),
  +        but I haven't figured out what condition signals that
  +        the apreq filter is being injected pre-, or post-,
  +        filter_init.  If redirects and subrequests can only
  +        happen in the content handler phase (or later),
  +        we can safely do the adjustment during filter_init()
  +        and the problem is solved. [joes]
   
       - Bring Perl documentation up to speed.