httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: httpd-2.0 STATUS
Date Sun, 11 Nov 2001 01:26:27 GMT
jerenkrantz    01/11/10 17:26:27

  Modified:    .        STATUS
  Log:
  This should be the last complaint about the input filtering.
  Needs more eyes...
  
  Revision  Changes    Path
  1.322     +17 -1     httpd-2.0/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/STATUS,v
  retrieving revision 1.321
  retrieving revision 1.322
  diff -u -r1.321 -r1.322
  --- STATUS	2001/11/11 01:10:21	1.321
  +++ STATUS	2001/11/11 01:26:27	1.322
  @@ -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 @@
         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>
  
  
  

Mime
View raw message