--- Ruediger Pluem <[EMAIL PROTECTED]> wrote:

> >>check_pipeline:  use AP_MODE_SPECULATIVE to check for data in the input
> filters
> >>to accomodate mod_ssl's input filter.  AP_MODE_EATCRLF is essentially a
> no-op
> >>in that filter.
> > 
> > EATCRLF was used here for a specific reason though - the fact that "many 
> > browsers" (says ap_core_input_filter) send newlines after request data - 
> > is that no longer the case?
> 
> Does this really matter? AFAICT we are ignoring empty lines
> in front of a request up to a certain limit (around line 573 in protocol.c)
> anyway, so I guess we don't need to eat them at check_pipeline.

that is true.  

I confirmed it by using a test case constructed to match Dean's description of
what the old browsers had to do to cope with the old CERN server, i.e, a POST
request with an extra blank line following the body.  the request itself was
handled normally.  then there is a 2nd call to ap_read_request and
read_request_line which executes the read loop that you pointed out, discards
the extra blank line, and then it breaks out of the loop due to rv 70014
(APR_EOF??) from ap_rgetline.

so we're good as far as I can tell, and our input filter path is cleaner.  I
would like to wait for a while to insure nobody turns up unexpected bugs due to
my change, then remove AP_MODE_EATCRLF support which appears to be dead.

Greg


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Reply via email to