On 31/05/06, Alexander Farber <[EMAIL PROTECTED]> wrote:
Hi
Why 8190? IMHO just malloc() a buffer of any length you like
(depends on what data len your app would typically receive),
then read() into it and if you exceed its sizeof while read() still
returns positive values (i.e. not -1 and not 0), realloc() the buffer.
That's nice, laconic. But still, as far as I understand, anything could
have came in under this scheme and I still have to figure out what
the real content size is (given that I do not trust CONTENT_LENGTH).
Its not like a big deal to write some checks, I ask just to make sure
I got it right.
On 5/31/06, vladas <[EMAIL PROTECTED]> wrote:
> So client could cause buff overflow by specifying wrong
> CONTENT_LENGTH in the custom-crafted headers. In that case,
> even the apache's 414 Request-URI Too Large could not prevent the
> problem,right?
>
> So the only solution I can figure out is allocate buffer >= than
> #define DEFAULT_LIMIT_REQUEST_LINE 8190 and to sscanf it to
> pick up the needed data from the headers sent from client.
>
> It seems like reinventing the wheel, really. Of course, I will google
> on it right away, but how e.g. mod_perl or other cgi's are dealing with it?
Maybe mod_perl and mod_cgi don't malloc() + read() the body,
but just pass stdin file descriptor to the user?
In which case the CONTENT_LENGTH would rely on what? Just on connection
socket?
(But I say this still without checking what really the mod_perl does, so
please feel free to ignore this).
poka
Alex
