Aaron Bannert wrote: > > On Wed, Oct 31, 2001 at 02:16:12PM -0500, Bill Stoddard 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? > > > > Yep, I think so. > > I wasn't quite sure if HUGE_STRING_LEN was the right way to go. > I'll switch it to LimitRequestFieldSize right away.
Slow down, hoss! ap_getline knows how big its caller's buffers are, which should be big enough to accomodate the two different limits. It also has logic to loop if there's no LF on the end of the "line", and logic to bail out if the caller's buffer size has been exceeded. So let's deal with the limits at a higher level where it's easier. I would suggest sticking with the HUGE_STRING_LEN limit in core_input_filter, but return that value instead of -1 in this case. ap_getline can then redrive the loop if the limits are really huge, or abort if appropriate. Once that works, we may have to twiddle some logic to get the appropriate HTTP error codes returned and logged. Greg
