Re: [ libapreq ] desesperatly need of .32 or .33
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ libapreq ] desesperatly need of .32 or .33
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
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/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ libapreq ] desesperatly need of .32 or .33
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ libapreq ] desesperatly need of .32 or .33
Matt Sergeant [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ libapreq ] desesperatly need of .32 or .33
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
