Rodent of Unusual Size wrote: > > [EMAIL PROTECTED] wrote: > > > > The core input filter would happily consume all the data > > you gave it in a header line, looking for that one LF. > > This patch limits that "getline" functionality to > > HUGE_STRING_LEN (8192 bytes). > > Shouldn't that use the value from the LimitRequestFieldSize > directive instead?
A couple of problems: * The core input filter has no idea if it's working on a request line or header line. They have different limits. ap_getline knows how big its caller's buffers are, but we're not passing this information down the filter chain when we're in "read a line" mode. * Returning -1 from core_input_filter bypasses the logic in read_request_line and get_mime_headers which set HTTP_REQUEST_URI_TOO_LARGE and HTTP_BAD_REQUEST respectively. They are expecting to see an excessively large positive number of bytes read. I didn't see anything in the error log when I tried this patch with a humungous request line. But that said, the server is more robust with this patch than without it. Greg
