httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: httpd-2.0/server/mpm/perchild perchild.c
Date Wed, 06 Dec 2000 23:47:33 GMT

> >   +    apr_get_userdata((void **)&foo, "PERCHILD_BUFFER", r->connection->pool);
> >   +    len = strlen(foo);
> Couldn't that content be binary data? The strlen() isn't going to work in
> that case.
> [ it could be binary on a file upload or a PUT ]

Nope.  At this point, we are ONLY dealing with header data.  I'm not
convinced that this works completely, because there may be some data on
in the bucket brigade that we haven't read yet, but the data that I am
doing a strlen on is definately ASCII data.

> >            ap_bucket_read(e, &str, &len, AP_NONBLOCK_READ);
> >   -        apr_pstrcat(f->r->pool, sconf->buffer, str);
> >   +        apr_pstrcat(f->c->pool, buffer, str);
> >   +
> >   +        apr_set_userdata(&buffer, "PERCHILD_BUFFER", apr_null_cleanup, f->c->pool);
> That set should probably be apr_set_userdata(buffer, ...) (no ampersand).
> The apr_pstrcat() will also be a bit wonky with binary data. [not to mention
> that the result value from the call isn't being used]

The strcat isn't an issue, because this is header data.  Not using the
returned data is a bug, as is the ampersand.

> Finally: who places the buffer into the userdata in the first place?

Nobody.  The first call gets NULL back, which is exactly what I
want.  After we have seen the first byte of data, this filter puts the
buffer in the userdata.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message