From: Justin Erenkrantz <jerenkrantz@apache.org>
Date: Sun, 11 Nov 2001 01:26:27 +0000 (+0000)
Subject: This should be the last complaint about the input filtering.
X-Git-Tag: 2.0.29~196
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=4bded7611a522655f0ff349b99e21421ed745a71;p=apache

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 60b01493b0..b0d946d302 100644
--- 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>