This should be the last complaint about the input filtering.

Needs more eyes...

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91843 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/STATUS b/STATUS
index 60b01493b0f4f86d9be7e7544943cd80e88cd1ae..b0d946d302826e6b1d35b98de193ddaa840e938a 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -1,5 +1,5 @@
 APACHE 2.0 STATUS:                                             -*-text-*-
-Last modified at [$Date: 2001/11/11 01:10:21 $]
+Last modified at [$Date: 2001/11/11 01:26:27 $]
 
 Release:
 
@@ -98,6 +98,22 @@ RELEASE SHOWSTOPPERS:
       Status: Justin is working on this as fast as he can.
               The core input filters, HTTP-related filters, mod_ssl, and
               mod_proxy are switched to the new logic.  
+              However, ap_getline() still needs to be refactored out.  But, 
+              there's a problem there: ap_getline() peeks ahead for MIME
+              continuation (first character on line is space or \t) and 
+              stores unused data in core_request_config which violates the
+              abstraction.  That's cheating.  So, we may not be able to 
+              implement this without setting some data aside (yuck!).
+              I believe this is OtherBill's main complaint with the current
+              filtering.
+              AIUI (correct me if I'm wrong!), OtherBill believes we 
+              should have a pushback option so that we can return unread 
+              data - this would solve this case.  However, my question to 
+              him is how do we handle stuff like mod_ssl - we can't "unread"
+              data.  So, do we have two brigades for each filter?  An in
+              brigade and a returned brigade?  That seems messy.  To
+              everyone else, can we refactor ap_getline() without pushback 
+              and how?
 
       - socket bucket and core input filter changes. see end of
         message ID (Feb 27): <20010227075326.S2297@lyra.org>