You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by Alexander Farber <al...@gmail.com> on 2007/10/19 10:49:27 UTC
Ap1: Reading POST-requests buggy? (not 0-terminated)
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.
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?
Thank you
Alex (a proud owner of Doug's and Nick's books)
--
http://preferans.de
Re: Ap1: Reading POST-requests buggy? (not 0-terminated)
Posted by Alexander Farber <al...@gmail.com>.
Hello,
I think it is a bug in the libapreq-1.33:
util_read() doesn't 0-terminate the received POST data,
but after that calls ap_getword() on it repeatedly.
Regards
Alex
--
http://preferans.de
Re: Ap1: Reading POST-requests buggy? (not 0-terminated)
Posted by Joe Lewis <jo...@joe-lewis.com>.
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
Re: Ap1: Reading POST-requests buggy? (not 0-terminated)
Posted by Alexander Farber <al...@gmail.com>.
That's why!! Thank you Nick.
On 10/19/07, Nick Kew <ni...@webthing.com> wrote:
> On Fri, 19 Oct 2007 10:49:27 +0200
> "Alexander Farber" <al...@gmail.com> wrote:
> > 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.
>
> But you should check up on the difference between ap_palloc
> and ap_pcalloc for the answer to your question.
Re: Ap1: Reading POST-requests buggy? (not 0-terminated)
Posted by Nick Kew <ni...@webthing.com>.
On Fri, 19 Oct 2007 10:49:27 +0200
"Alexander Farber" <al...@gmail.com> 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.
That looks like very, very old and obsolete code (pre-APR).
But you should check up on the difference between ap_palloc
and ap_pcalloc for the answer to your question.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/