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.