--- 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
