On 3/1/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> > I think this is checking that the amount of data *already* received is
> > larger than maxinput, and if so, then rejecting. The idea is to not
> > read that much data in the first place.
>
>
> Yes, by the last buffer size only, it may not read the whole buffer, so
> cheking befor for requested size is not accurate yet, i may ask for 4096
> bytes but read only 100 for whatever reasons.
What happens if you set maxinput to 20MB, and a user tries to upload a
21MB image? Do they get an error message after uploading 20MB + ~8k?
That's how I'm reading it.
All modern browsers send a content-length header. Maybe we should
check the reqPtr->length field as soon as it's parsed. Round about
line 1760 in driver.c:
s = Ns_SetIGet(reqPtr->headers, "content-length");
if (s != NULL) {
int length;
/*
* Honour meaningfull remote
* content-length hints only.
*/
length = atoi(s);
if (length >= 0) {
reqPtr->length = length;
}
/* Check for maxinput here? */
}
> > I didn't look carefully so it may only be overshooting by the receive
> > buffer size or some such, but the same principle applies to the
> > following check for max headers. Here the headers have been
> > completely parsed into an Ns_Set structure, and *then* the size is
> > checked. Too late... :-(
>
> It does it after each line only, whatever amount was read is in the
> buffer already, so we parse it line by line and i check after each line.
It's kind of odd when reading the code that it overshoots by one, but OK...
