httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Lewis <...@joe-lewis.com>
Subject Re: Ap1: Reading POST-requests buggy? (not 0-terminated)
Date Fri, 19 Oct 2007 13:14:44 GMT
Alexander Farber wrote:
> Hello,
>
> the libapreq calls util_read() function -
> http://search.cpan.org/src/DOUGM/libapreq-0.31/c/apache_request.c
> which allocates a buffer with (r->remaining + 1) bytes.
>
> Then it reads up to r->remaining bytes by calling
> ap_get_client_block() and memcpy() repeatedly.
>
> Neither util_read(), nor ap_get_client_block()
> insert a terminating 0 at the end of the buffer.
>   

That is correct.  Not even the output filters should be relying on a
NULL-terminated string - not all programming languages use a NULL
character to mark the end of a string, and as well, nothing inside of
Apache should rely on NULL termination, either.  (I found that out the
hard way trying to use the regular string functions on data that didn't
have NULL's, causing segmentation faults.)

> After that the buffer is passed to split_to_parms()
> which calls ap_getword() repeatedly.
>
> So, is it a bug please? Does it maybe only work
> because web clients are nice enough to send
> a terminating 0 at the end of their POST requests?
>   

No, it isn't a bug.  Yes, it only works sometimes because a lot of
clients do send NULL characters.  The modules need to not rely on a NULL
character, and should use the other fields in the request/filter
structures that tell how long the chunk of data is.

Joe
-- 
Joseph Lewis <http://sharktooth.org/>
"Divide the fire, and you will sooner put it out." - Publius Syrus

Mime
View raw message