[ libapreq ] desesperatly need of .32 or .33

[Thierry-Michel Barral <kk...@electron-libre.com>]

Hi everyone,

I'm using Apache::Request, and I've encountered a bug !
[
I've done a POST multiform data, and the first field, a textarea, could contains at the end some garbage. Garbage because data is changing.
]

I'm quite sure [ after a quick glance at mod_perl ML archive] one of the patches proposed could solve the problem.

So I need desesperatly a new version of libapreq, the .32, or .33 if it's finished !

I do not know if Doug still maintains it, or if it's someone else.....

But please, could it be possible to see very very soon a new release ?

thanks,

kktos
365 Corp

Re: [ libapreq ] desesperatly need of .32 or .33

[Jim Winstead <ji...@trainedmonkey.com>]

On Nov 22, Joe Schaefer wrote:
> But before anyone bites off more than they can chew, perhaps some 
> discussion of the current bugs and future needs for libapreq should 
> be aired out.

the issues i know of:

* memory bloat from multipart buffer code (but there's your patch
and the one i've sent the list that both address this)

* workaround to handle multipart/form-data data sent from internet
explorer on the macintosh from forms with image submits which are
sent with an incorrectly terminated boundary string, if i remember
the details correctly. the patch i've sent to the list addresses
this, too.

* in ApacheRequest_parse_urlencoded, 'data' isn't initialized
properly, which can result in processes spinning out of control.
(fixed in the patch i've sent before, but a trivial fix anyway.)

* the content-type tests don't handle encodings quite right
(patch: http://www.mail-archive.com/modperl@apache.org/msg08188.html)

* i seem to remember there being a bug in the cookie handling that
choked when an undefined value was passed in. easy to fix once the
details are dug up. (this may actually have been something in
mod_perl itself that i'm misremembering.)

* win32 patches?

things that could be added to libapreq:

* intelligent cross-request-phase handling of posted form data, a
la RequestNotes. (it looks to me like the data is already allocated
out of the per-request pool, so it should just be a matter of
stuffing the data in the real request rec instead of the Apache::Request
object so the next Apache::Request object can see the data.)

* $apr->parms documented (possibly with a better name, as doug
has suggested)

* someone has suggested that Apache::Cookie->new should check
the first argument to make sure it is passed the right thing.
(http://www.mail-archive.com/modperl@apache.org/msg05151.html)

* the whole thing just folded into mod_perl since it is, in my
opinion, indispensable. :)

there's also the few things in the ToDo file in the libapreq
distribution.

jim

Re: [ libapreq ] desesperatly need of .32 or .33

[Jeremy Howard <j...@howard.fm>]

> But before anyone bites off more than they can chew, perhaps some
> discussion of the current bugs and future needs for libapreq should
> be aired out.
>
> My own problems with libapreq revolved around the multipart buffer
> code, and since I patched it a while back, I haven't bumped into
> any other snags.
>
I agree--the multipart buffer memory issues are the key problem with the
current 'official' release. There are at least two multipart buffer fixes
around though, so it would be nice to merge one of these into the CPAN
distribution.

Re: [ libapreq ] desesperatly need of .32 or .33

[Joe Schaefer <jo...@sunstarsys.com>]

Matt Sergeant <ma...@sergeant.org> writes:

> Doug mentioned to me at ApacheCon (or it may have been back at TPC) that
> he would like someone else to take over maintainence of
> Apache::Request. If nobody volunteers, I'm willing to look at doing so,
> although I've only just started that long road into using XS, so I'm more
> likely to spend time applying patches than writing them.

I'd be happy to the help with the bulk of whatever needs fixing,
however I'm somewhat reluctant to volunteer to maintain such 
a critical package since

1) I have no experience maintaining CPAN'd perl packages,
2) other than broken stuff, I wouldn't seek to change much code 
  (especially *not* the API, but anything that reduces the memory
   footprint and/or increases performance would be of interest)
3) my familiarity with XS and perlguts is cursory at best.

But before anyone bites off more than they can chew, perhaps some 
discussion of the current bugs and future needs for libapreq should 
be aired out.

My own problems with libapreq revolved around the multipart buffer 
code, and since I patched it a while back, I haven't bumped into 
any other snags.

What are the other unresolved issues with libapreq? How much of the
"undocumented" API (like $q->parms) is in use?

Regards.
-- 
Joe Schaefer
joe@sunstarsys.com

Re: [ libapreq ] desesperatly need of .32 or .33

[Thierry-Michel Barral <kk...@electron-libre.com>]

Thierry-Michel Barral [
    Hi everyone,
    I'm using Apache::Request, and I've encountered a bug !
    please, could it be possible to see very very soon a new release ?
]

<Matt>
Doug mentioned to me at ApacheCon (or it may have been back at TPC) that
he would like someone else to take over maintainence of
Apache::Request. If nobody volunteers, I'm willing to look at doing so,
although I've only just started that long road into using XS, so I'm more
likely to spend time applying patches than writing them.
</Matt>

I'm not sure I can do it myself, sorry [not good/talented/... enough] :( .

It could be really great if you can spend some time applying the
patches.......
For me, but I'm pretty sure others would be very happy, because, after a
glance at this mailing list, I've concluded each guy has is own libapreq !

thanks for your help, in advance :o)

kktos

Re: [ libapreq ] desesperatly need of .32 or .33

[Matt Sergeant <ma...@sergeant.org>]

On Wed, 22 Nov 2000, Thierry-Michel Barral wrote:

> Hi everyone,
> 
> I'm using Apache::Request, and I've encountered a bug !
> [
> I've done a POST multiform data, and the first field, a textarea, could contains at the end some garbage. Garbage because data is changing.
> ]
> 
> I'm quite sure [ after a quick glance at mod_perl ML archive] one of the patches proposed could solve the problem.
> 
> So I need desesperatly a new version of libapreq, the .32, or .33 if it's finished !
> 
> I do not know if Doug still maintains it, or if it's someone else.....
> 
> But please, could it be possible to see very very soon a new release ?

Doug mentioned to me at ApacheCon (or it may have been back at TPC) that
he would like someone else to take over maintainence of
Apache::Request. If nobody volunteers, I'm willing to look at doing so,
although I've only just started that long road into using XS, so I'm more
likely to spend time applying patches than writing them.

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\