Re: test/zb.c

On May 8, 2006, at 4:24 PM, Garrett Rooney wrote: On 5/8/06, Sander Temme <[EMAIL PROTECTED]> wrote: Found on http://svn.apache.org/viewcvs.cgi?rev=80572&view=rev Does an archive of that apache-core mailing list mentioned above exist? Yes, it does. The first few years of archives of the

Re: test/zb.c

On 5/8/06, Sander Temme <[EMAIL PROTECTED]> wrote: Found on http://svn.apache.org/viewcvs.cgi?rev=80572&view=rev Does an archive of that apache-core mailing list mentioned above exist? Yes, it does. The first few years of archives of the httpd pmc mailing list are actually the archives of th

Re: test/zb.c

On May 8, 2006, at 9:10 AM, Thom May wrote: * Garrett Rooney ([EMAIL PROTECTED]) wrote : On 5/8/06, Thom May <[EMAIL PROTECTED]> wrote: Hey, just had a report in debian that test/zb.c's license doesn't necessarily allow you to modify and redistribute the code. A quick grep around doesn't

Problem with mod_cgid and large POST queries

If I use TCP socket instead of the default unix doman socket for the Scriptsock directive, I have a problem when there is a huge post payload. I have a form that sends a huge volume of data to a CGI script. I get an error on the browser. I did some debugging and found that the CGI process terminat

DO NOT REPLY [Bug 39522] - Web services implemented in ASP.NET leak memory with mod_aspdotnet

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 39522] New: - Web services implemented in ASP.NET leak memory with mod_aspdotnet

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Laying undead myths to rest

Joseph Dane wrote: Joshua Slive <[EMAIL PROTECTED]> writes: In very early versions of the Apache HTTP Server, the AddType directive was also used to activate special server-side processing (such as mod_include or PHP) by assigning "magic" MIME types to files. This can create problems in more

[Q] is this kind of patches interesting ?

Hi, from time to time, I spend time to look at apache code source to see if something can be cleaned up a bit in the hope either to speed it up or, at least, to make it more readable. For example : http://issues.apache.org/bugzilla/show_bug.cgi?id=39518 http://issues.apache.org/bugzilla/show_bug.

Re: Laying undead myths to rest

On 5/8/06, Joseph Dane <[EMAIL PROTECTED]> wrote: Joshua Slive <[EMAIL PROTECTED]> writes: > In very early versions of the Apache HTTP Server, the > AddType directive was also used to activate > special server-side processing (such as mod_include > or PHP) by assigning "magic" MIME types to file

Re: Laying undead myths to rest

Joshua Slive <[EMAIL PROTECTED]> writes: > In very early versions of the Apache HTTP Server, the > AddType directive was also used to activate > special server-side processing (such as mod_include > or PHP) by assigning "magic" MIME types to files. This can create > problems in more recent versi

Re: 1.3.35 status: Was: Re: Dealing with Regressions

Jim Jagielski wrote: In any case, this is notice that I will be RM for 1.3.36 Thanks for voulenteering :) My point in the earlier thread is that I'll make a 1.3.36 binary for windows, leave it on the mirror for three days. But will then pull down that binary, and notes about 1.3, leaving use

1.3.35 status: Was: Re: Dealing with Regressions

There are several bug reports due to the updated Include code (eg: 39490, 39513 and 39516). Looks like we got bitten by what we usually get bitten by: last minute updates :( My plan is that we release 1.3.36 very soon to address this. I'd prefer a fix that (1) doesn't replicate lots of code and (

Re: Dealing with Regressions

What I did is reversed #396294... this keeps HEAD in a non-regressed state and gives us time to come up with a full fix.

Re: Dealing with Regressions

+1 here as well, but could you attach this to both bugs and get confirmation that the double-free and wildcards again act as expected for our reporters after applying the patch? Bill Jim Jagielski wrote: I'd prefer just fixing the regression and keeping both behaviors :) +1 On May 8, 2006, at

[Bug 39513] - apache 1.3.35 - *** glibc detected *** double free or corruption (!prev) error on startup]

Whoa nelly - sorry team for the +1 from me, this one really stank to high heaven (this bug, as well as the wildcard Include crippled). Unfortunately my environment noted neither. As good an arguement as any, I think, that httpd 1.3 is dead - dead - dead for all feature patches. If it isn't a (s

Re: test/zb.c

* Garrett Rooney ([EMAIL PROTECTED]) wrote : > On 5/8/06, Thom May <[EMAIL PROTECTED]> wrote: > >Hey, > >just had a report in debian that test/zb.c's license doesn't necessarily > >allow you to modify and redistribute the code. A quick grep around doesn't > >reveal any uses of this code in our tree

Re: Dealing with Regressions

I'd prefer just fixing the regression and keeping both behaviors :) +1 On May 8, 2006, at 10:45 AM, Colm MacCarthaigh wrote: On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote: That is an unexpected and unwelcome regression. Yep, my bad, I never had such a block in my testing lar

Re: test/zb.c

On 5/8/06, Thom May <[EMAIL PROTECTED]> wrote: Hey, just had a report in debian that test/zb.c's license doesn't necessarily allow you to modify and redistribute the code. A quick grep around doesn't reveal any uses of this code in our tree, and given that we have support/ab.c it seems strange to

test/zb.c

Hey, just had a report in debian that test/zb.c's license doesn't necessarily allow you to modify and redistribute the code. A quick grep around doesn't reveal any uses of this code in our tree, and given that we have support/ab.c it seems strange to carry both. Can we just drop it? -Thom

Re: Dealing with Regressions

On Mon, May 8, 2006 1:36 pm, Nick Kew wrote: > We should do better than leaving the users to rediscover and deal with > regressions themselves, once we know there's a problem. Can I suggest > an Errata page, to list *all* known regressions in current/recent > versions, > linked from the main page

Re: Dealing with Regressions

On Mon, May 08, 2006 at 03:45:21PM +0100, Colm MacCarthaigh wrote: > Yep, my bad, I never had such a block in my testing largely because I > didn't even know 1.3.x had that feature, *sigh*, it's not even > documented and I can't see it in a changelog and it didn't have that > functionality when I f

Re: Dealing with Regressions

On Mon, May 08, 2006 at 10:12:58AM -0400, Jim Jagielski wrote: > That is an unexpected and unwelcome regression. Yep, my bad, I never had such a block in my testing largely because I didn't even know 1.3.x had that feature, *sigh*, it's not even documented and I can't see it in a changelog and it

Re: Laying undead myths to rest

On Monday 08 May 2006 14:25, Joshua Slive wrote: > On 5/8/06, Nick Kew <[EMAIL PROTECTED]> wrote: > > There are a few undead "apache myths" still floating around, > > due to clueless third-party tutorials. I wonder if there's any value > > in countering these zombies with specific notes in our doc

Re: Dealing with Regressions

On Monday 08 May 2006 14:56, Niklas Edmundsson wrote: > On Mon, 8 May 2006, Jeff Trawick wrote: > >> We should do better than leaving the users to rediscover and deal with > >> regressions themselves, once we know there's a problem. Can I suggest > >> an Errata page, to list *all* known regression

Re: [PATCH 4/6] fork() failure handling

Nick: > That makes sense, and doesn't seem to break anything. Basically you're > saying there's a mismatch between a process-level failure and setting > a thread-level slot. So why was it there in the first place? It came over from the prefork MPM code, I think. Chris. -- GPG Key ID: 366A

Re: Dealing with Regressions

On May 8, 2006, at 7:36 AM, Nick Kew wrote: OK, we all know we get some embarrassing regressions in our new releases. PR#39490 in 1.3.35. That is an unexpected and unwelcome regression. If I had known about it I would have vetoed the patch. I'd be willing to actually release a 1.3.36 simply

Re: Dealing with Regressions

On Mon, 8 May 2006, Jeff Trawick wrote: We should do better than leaving the users to rediscover and deal with regressions themselves, once we know there's a problem. Can I suggest an Errata page, to list *all* known regressions in current/recent versions, linked from the main page alongside "D

Re: Laying undead myths to rest

On 5/8/06, Nick Kew <[EMAIL PROTECTED]> wrote: There are a few undead "apache myths" still floating around, due to clueless third-party tutorials. I wonder if there's any value in countering these zombies with specific notes in our documentation. Here's an example patch of the kind I have in mi

Documentation on MPM's

Hi All, Anyone have a link to some clear documentation on the MPM interface in Apache2? The MPM for OS/2 on Apache2 was originally written for the EMX compiler/library and I've updated the port to the latest GCC on OS/2 (which uses a similar approach to cygwin), however have problems with modph

Laying undead myths to rest

There are a few undead "apache myths" still floating around, due to clueless third-party tutorials. I wonder if there's any value in countering these zombies with specific notes in our documentation. Here's an example patch of the kind I have in mind: --- mod/mod_mime.xml(revision 404858) ++

[jira] Commented: (MODPYTHON-104) Allow Python code callouts with mod_include (SSI).

[ http://issues.apache.org/jira/browse/MODPYTHON-104?page=comments#action_12378409 ] Graham Dumpleton commented on MODPYTHON-104: The Apache crash when a Python exception occurs has been eliminated, but at the same time have disabled details of

Re: Dealing with Regressions

On 5/8/06, Nick Kew <[EMAIL PROTECTED]> wrote: OK, we all know we get some embarrassing regressions in our new releases. PR#39490 in 1.3.35. Or 2.0.55 being effectively unusable in a proxy due to PR#37145. Look at the number of duplicates of 37145 - that's a lot of people with the confidence t

Dealing with Regressions

OK, we all know we get some embarrassing regressions in our new releases. PR#39490 in 1.3.35. Or 2.0.55 being effectively unusable in a proxy due to PR#37145. Look at the number of duplicates of 37145 - that's a lot of people with the confidence to report it, and who didn't find it 'cos it's mar

Re: [PATCH 5/6] hard restart on Linux #38737

On Mon, May 08, 2006 at 06:19:59AM -0400, Jeff Trawick wrote: > >Question: what other side-effects might this have? > > unpredictable if somebody/something sends AP_SIG_GRACEFUL to the child > process; it will land on random worker thread > > (it might be nice for debugging if you could make proc

Re: [PATCH 5/6] hard restart on Linux #38737

On 5/7/06, Nick Kew <[EMAIL PROTECTED]> wrote: On Thursday 04 May 2006 19:16, Chris Darroch wrote: > +#ifdef HAVE_PTHREAD_KILL > +unblock_signal(WORKER_SIGNAL); > +apr_signal(WORKER_SIGNAL, dummy_signal_handler); > +#endif > + OK, unblock a signal. This happens after child_init, but pr