You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2002/10/26 20:02:08 UTC

libapreq 1.1

I'd like to put together a 1.1 release in November that:

    a) includes full OS X support for both the perl & C API's
    b) includes Doug's Request.xs upload patches for perl 5.8.0
    c) documents the problems with using '\0' bytes in
       cookies and request params.

I volunteer to package up release candidates again and 
work with the OS X user community and see that (a) & (b) 
are OK.  Would anyone like to volunteer a doc patch for (c)?

-- 
Joe Schaefer

Re: libapreq 1.1

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes 
on October 26, 2002:

> I'd like to put together a 1.1 release in November that:
> 
>     a) includes full OS X support for both the perl & C API's
>     b) includes Doug's Request.xs upload patches for perl 5.8.0
>     c) documents the problems with using '\0' bytes in
>        cookies and request params.
> 
> I volunteer to package up release candidates again and 
> work with the OS X user community and see that (a) & (b) 
> are OK.  Would anyone like to volunteer a doc patch for (c)?

Something's got to change here.  It should not take this long
to put out a maintenance release.  Version 1.0 of Apache::Request 
segfaults with the current version of perl (5.8.0), and 
libapreq-1.0 does not support OS X at all.  Thanks to the *user*
*community*, we have a 1.1 that fixes both problems.

Please reward them by releasing 1.1, soon.

Thanks.

-- 
Joe Schaefer

Re: libapreq 1.1

Posted by Joe Schaefer <jo...@sunstarsys.com>.
[cc-d the apreq-dev list]

"Issac Goldstand" <ma...@beamartyr.net> writes:

> You mean just sorta explain to perl people why C will chocke on a =0 in
> char*?  If so, I think I can do it...  

More or less.  The problem is that our underlying C structures
use (char *) to hold unencoded data strings, so any encoded null-bytes
are treated as end-of-string markers ('\0').  

I've taken care of this problem in apreq-2 via apreq_tables, but
it impacts the API way too much to backport them to apreq-1.

> You'll have to remind me where the CVS repository is, though...  It's
> been a while ;-)

  http://www.apache.org/~joes/

Thanks, Issac.

-- 
Joe Schaefer