> > 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?
EATCRLF started out life as AP_MODE_PEEK. its mission was to see if any more input data was stashed in the pipeline in order to know if it is appropriate to flush the output filters, without doing a read() syscall. then someone added the side effect of eating the single CRLFs from old browsers. an inappropriate design in my opinion. the filters should be lean and mean and relatively dumb. then someone else decided to rewrite the input filters and rename MODE_PEEK. the result was that it got named after its side effect and redundant code was added as MODE_SPECULATIVE which was used in mod_ssl. my thoughts: don't try to optimize for old browsers within the core filters. if they really need any special attention (I doubt it), do it at the protocol level, above the filters. Greg __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
