Re: A proposal...

On Thu, Apr 26, 2018 at 10:13 AM, Jim Jagielski wrote: > >> On Apr 25, 2018, at 1:50 PM, William A Rowe Jr wrote: >> >> Because of our conflation of patch and enhancement, > > It is hardly just "our"... tons and tons of s/w uses the patch number bump for

Re: A proposal...

> On Apr 25, 2018, at 1:50 PM, William A Rowe Jr wrote: > > Because of our conflation of patch and enhancement, It is hardly just "our"... tons and tons of s/w uses the patch number bump for not only patches but also features and enhancements, including our

Re: A proposal...

On Wed, Apr 25, 2018 at 1:50 PM, William A Rowe Jr wrote: > On Tue, Apr 24, 2018 at 3:46 PM, Eric Covener wrote: One thing you mention above is "wait for a new minor release". I can definitely see that being an issue for our current maj.minor

Re: A proposal...

On Tue, Apr 24, 2018 at 3:46 PM, Eric Covener wrote: >>> One thing you mention above is "wait for a new minor release". I can >>> definitely see that being an issue for our current maj.minor layout given >>> that minor bumps are measured in years. In this proposal, unless

Re: A proposal...

>> One thing you mention above is "wait for a new minor release". I can >> definitely see that being an issue for our current maj.minor layout given >> that minor bumps are measured in years. In this proposal, unless there's a >> pressing need to send out a patch release right now, the next

Re: A proposal...

Am 24.04.2018 um 19:58 schrieb Daniel Ruggeri: On 2018-04-24 09:22, Eric Covener wrote: On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr wrote: On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: Yes, exactly correct. We have three "contracts" to

Re: A proposal...

At the pace of our (currently 'minor', contrast to 'patch') releases there are about 2-4 / year. I agree with the idea of monthly bug fix patch releases. Declaring the first minor of each year as LTS for 2 years, we could get security fixes into legacy users hands. It would be a good starting

Re: A proposal...

> Should we also need some kind of LTS version? If yes, how to choose them? I think it would be required with frequent minor releases.

Re: A proposal...

Le 24/04/2018 à 19:58, Daniel Ruggeri a écrit : One thing you mention above is "wait for a new minor release". I can definitely see that being an issue for our current maj.minor layout given that minor bumps are measured in years. In this proposal, unless there's a pressing need to send out a

Re: A proposal...

On 2018-04-24 09:22, Eric Covener wrote: On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr wrote: On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: Yes, exactly correct. We have three "contracts" to keep that I think aligns very well with the

Re: A proposal...

On Tue, Apr 24, 2018 at 4:22 PM, Eric Covener wrote: > On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr > wrote: >> On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: Yes, exactly correct. We have three "contracts" to keep

Re: A proposal...

As express by others, please don't ! IMHO, ONE language/framework is all what we need. Having a set of unrelated materials will bring nightmares and something hard, not to say impossible, to maintain/understand. So we should keep it as-is, or switch to something new. But trying to please

Re: A proposal...

On Tue, Apr 24, 2018 at 10:08 AM, William A Rowe Jr wrote: > On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: >>> Yes, exactly correct. We have three "contracts" to keep that I think aligns >>> very well with the following semver "contracts": >>>

Re: A proposal...

On Tue, Apr 24, 2018 at 8:37 AM, Plüm, Rüdiger, Vodafone Group wrote: > > If we switch the framework we need to consider that with all gaps we have, we > already have > a large amount of tests in the current framework that need to be ported over > time. The OpenSSL

Re: A proposal...

On Tue, Apr 24, 2018 at 8:27 AM, Eric Covener wrote: >> Yes, exactly correct. We have three "contracts" to keep that I think aligns >> very well with the following semver "contracts": >> Major => API/ABI compatibility for modules >> Minor => Feature and directives >> Patch =>

Re: A proposal...

On Tue, Apr 24, 2018 at 8:50 AM, Jim Jagielski wrote: > One idea is that we setup, using the existing perl test framework, a sort of > "catch all" test, where the framework simply runs all scripts from a subdir > via system() (or whatever), and the reports success or failure.

Re: A proposal...

> Yes, exactly correct. We have three "contracts" to keep that I think aligns > very well with the following semver "contracts": > Major => API/ABI compatibility for modules > Minor => Feature and directives > Patch => Functional and configuration syntax guarantees > > Demonstrating by way of a

Re: A proposal...

On 04/24/2018 02:52 PM, Daniel Ruggeri wrote: > > In all cases, the changelog would clearly state the changes and we would ship > what we consider to be the best default config. Ideally, we would also point > the changelog entry to the SVN patches which implement the change so > downstream

Re: A proposal...

Hi, Jim; Further to that point, simply reaping the exit code of zero or non-zero should be enough for a test to communicate success or failure. My only concern with this concept is that it could make our testing framework require a *very* unique set of system libraries, binaries and

Re: A proposal...

gt; wrote: >>> >>> >>>> -Ursprüngliche Nachricht- >>>> Von: Rainer Jung <rainer.j...@kippdata.de> >>>> Gesendet: Montag, 23. April 2018 16:47 >>>> An: dev@httpd.apache.org >>>> Betreff: Re: A proposal... >>>>

Re: A proposal...

One idea is that we setup, using the existing perl test framework, a sort of "catch all" test, where the framework simply runs all scripts from a subdir via system() (or whatever), and the reports success or failure. Those scripts could be written in anything. This would mean that people could

Re: A proposal...

gt;> -Ursprüngliche Nachricht- >>>> Von: Rainer Jung <rainer.j...@kippdata.de> >>>> Gesendet: Montag, 23. April 2018 16:47 >>>> An: dev@httpd.apache.org >>>> Betreff: Re: A proposal... >>>> >>>> Am 23.04.2018 um 16:0

Re: A proposal...

.j...@kippdata.de> >>> Gesendet: Montag, 23. April 2018 16:47 >>> An: dev@httpd.apache.org >>> Betreff: Re: A proposal... >>> >>> Am 23.04.2018 um 16:00 schrieb Jim Jagielski: >>>> It seems that, IMO, if there was not so much concern about >

Re: A proposal...

ril 2018 16:47 An: dev@httpd.apache.org Betreff: Re: A proposal... Am 23.04.2018 um 16:00 schrieb Jim Jagielski: It seems that, IMO, if there was not so much concern about "regressions" in releases, this whole revisit-versioning debate would not have come up. This implies, to me at least, that the r

Re: A proposal...

On April 24, 2018 1:38:26 AM CDT, "Plüm, Rüdiger, Vodafone Group" <ruediger.pl...@vodafone.com> wrote: > > >> -Ursprüngliche Nachricht- >> Von: Rainer Jung <rainer.j...@kippdata.de> >> Gesendet: Montag, 23. April 2018 16:47 >>

Re: A proposal...

Le 23/04/2018 à 23:09, Mark Blackman a écrit : On 23 Apr 2018, at 19:17, Christophe Jaillet wrote: Le 23/04/2018 à 16:00, Jim Jagielski a écrit : It seems that, IMO, if there was not so much concern about "regressions" in releases, this whole

Re: A proposal...

> On 23 Apr 2018, at 19:17, Christophe Jaillet > wrote: > > Le 23/04/2018 à 16:00, Jim Jagielski a écrit : >> It seems that, IMO, if there was not so much concern about "regressions" in >> releases, this whole revisit-versioning debate would not have come up.

Re: A proposal...

> Hi, > +1000 on my side for more tests. > > But, IMHO, the perl framework is complex to understand for most of us. >From what I saw, the preferred scripting language having access to httpd's >internal seem to be lua at the present time. I also think that redoing (recoding) the testing

Re: A proposal...

On Mon, Apr 23, 2018 at 1:05 PM, Jim Jagielski wrote: > >> On Apr 23, 2018, at 12:54 PM, William A Rowe Jr wrote: >> >> +1; I see any "patch" releases (semver definition) as adopting well-tested >> bug >> fixes. In some cases, complex patches could arrive

Re: A proposal...

On Mon, Apr 23, 2018 at 11:17 AM, Christophe Jaillet wrote: > Le 23/04/2018 à 16:00, Jim Jagielski a écrit : >> >> It seems that, IMO, if there was not so much concern about "regressions" >> in releases, this whole revisit-versioning debate would not have come up.

Re: A proposal...

Le 23/04/2018 à 16:00, Jim Jagielski a écrit : It seems that, IMO, if there was not so much concern about "regressions" in releases, this whole revisit-versioning debate would not have come up. This implies, to me at least, that the root cause (as I've said before) appears to be one related to

Re: A proposal...

> On Apr 23, 2018, at 12:54 PM, William A Rowe Jr wrote: > > > +1; I see any "patch" releases (semver definition) as adopting well-tested bug > fixes. In some cases, complex patches could arrive first on a new minor branch > for longer alpha/beta scrutiny, before being

Re: A proposal...

On Mon, Apr 23, 2018 at 9:47 AM, Rainer Jung wrote: > Am 23.04.2018 um 16:00 schrieb Jim Jagielski: >> >> It seems that, IMO, if there was not so much concern about "regressions" >> in releases, this whole revisit-versioning debate would not have come up. Additional

Re: A proposal...

Just a side node, some days ago I just realized that the source package of the apache2 package in Debian seems to include the test suite for the purpose of running it as part of the continuous integration test 'run-test-suite': https://ci.debian.net/packages/a/apache2/ In my recently provided

Re: A proposal...

> Am 23.04.2018 um 17:07 schrieb Stefan Eissing : > > I do that for stuff I wrote myself. Not because I care only about that, but > because the coverage and documentation of other server parts does give me an i > dea of what should work and what should not. So, I

Re: A proposal...

> Am 23.04.2018 um 16:00 schrieb Jim Jagielski : > > It seems that, IMO, if there was not so much concern about "regressions" in > releases, this whole revisit-versioning debate would not have come up. This > implies, to me at least, that the root cause (as I've said before)

Re: A proposal...

> On Apr 23, 2018, at 10:22 AM, Graham Leggett wrote: > > My perl knowledge is very rusty, making perl tests is going to be harder for > some than others. > Yeah, that IS an issue. It is also not as well documented as desired[1]. Should we look at using something external

Re: A proposal...

On 2018-04-23 09:00, Jim Jagielski wrote: It seems that, IMO, if there was not so much concern about "regressions" in releases, this whole revisit-versioning debate would not have come up. This implies, to me at least, that the root cause (as I've said before) appears to be one related to QA and

Re: A proposal...

Am 23.04.2018 um 16:00 schrieb Jim Jagielski: It seems that, IMO, if there was not so much concern about "regressions" in releases, this whole revisit-versioning debate would not have come up. This implies, to me at least, that the root cause (as I've said before) appears to be one related to

Re: A proposal...

On 23 Apr 2018, at 4:00 PM, Jim Jagielski wrote: > It seems that, IMO, if there was not so much concern about "regressions" in > releases, this whole revisit-versioning debate would not have come up. This > implies, to me at least, that the root cause (as I've said before)

Re: [API proposal] TSHttpTxnCacheLookupUrlSet()

Probably the wrong list... Regards, Yann On Mon, May 4, 2015 at 8:24 PM, Leif Hedstrom zw...@apache.org wrote: This new API is the inverse of an existing API, TSHttpTxnCacheLookupUrlGet(). It also works similar to another existing API, TSCacheUrlSet(). The main difference between this new

Re: UseListenScheme proposal

On 11 Jul 2013, at 03:12, Chris Darroch wrote: The idea is to introduce a non-default UseListenScheme On setting which uses the scheme from the Listen directive when constructing self-referencing URLs: Can you clarify for the lazy among us how this might interact with existing configuration

Re: UseListenScheme proposal

Nick: The idea is to introduce a non-default UseListenScheme On setting which uses the scheme from the Listen directive when constructing self-referencing URLs: Can you clarify for the lazy among us how this might interact with existing configuration options for self-referencing URLs? I'm

Re: UseListenScheme proposal

On 11 Jul 2013, at 16:23, Chris Darroch wrote: It's pretty basic None, so far as I can tell ... I didn't see a way to do this and retain backwards-compatibility OK, I guess that explains for me why you didn't discuss my questions in your previous post. They weren't relevant! I think

Re: [RFC] Proposal to save a few hundreds bytes in the 'request' pool

On 13 May 2013, at 22:04, Christophe JAILLET christophe.jail...@wanadoo.fr wrote: trying to reduce httpd memory usage, I've worked on ap_rgetline_core in protocol.c. This function gets a line of protocol input. To do so, : - it processes the apr_bucket_brigade it is given in

Re: STATUS proposal for 2.2.x

On Dec 4, 2010, at 9:56 AM, Daniel Ruggeri wrote: Good day, all; I would appreciate it if a committer could spare a moment to patch the 2.2 STATUS file to include this as a proposal (a +1 would be really great, too). For reference, the patch is also attached. The trunk patch was applied

Re: Backport proposal for CVE-2009-3555

On 09.11.2009 23:28, Rainer Jung wrote: I did a first try on backporting the CVE-2009-3555 patch to 2.0: http://people.apache.org/~rjung/patches/cve-2009-3555_httpd_2_0_x.patch I hadn't yet time for intensive testing, but first tests looked OK. I noticed I couldn't log the SSL_SESSION_ID,

Re: [mod_fcgid proposal] defining processing options for particular commands

Ricardo Cantu wrote: On Friday 02 October 2009 11:10:25 am Barry Scott wrote: Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk wrote: Jeff Trawick wrote: (instead of based on uri or vhost)

Re: [mod_fcgid proposal] defining processing options for particular commands

On Fri, Oct 2, 2009 at 10:47 AM, Ricardo Cantu rica...@smartcsc.com wrote: mod_fastcgi's FastCgiServer directive is similar in some respects to the one I propose in this thread, but it has a key difference: It implies that at least one instance/process will be maintained at all times,

Re: [mod_fcgid proposal] defining processing options for particular commands

Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n MinProcesses n MaxProcesses n MaxRequestsPerProcess n InitialEnv var[=val] ... class (the names of these options follow my proposal for the names of existing

Re: [mod_fcgid proposal] defining processing options for particular commands

On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott barry.sc...@onelan.co.ukwrote: Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n MinProcesses n MaxProcesses n MaxRequestsPerProcess n InitialEnv var[=val] ...

Re: [mod_fcgid proposal] defining processing options for particular commands

On Friday 02 October 2009 5:35:03 am Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott barry.sc...@onelan.co.ukwrote: Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n MinProcesses n

Re: [mod_fcgid proposal] defining processing options for particular commands

On Fri, Oct 2, 2009 at 9:01 AM, Ricardo Cantu rica...@smartcsc.com wrote: On Friday 02 October 2009 5:35:03 am Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott barry.sc...@onelan.co.uk wrote: Is it possible to also ask for the fcgi process to be started before any

Re: [mod_fcgid proposal] defining processing options for particular commands

On Friday 02 October 2009 8:14:14 am Jeff Trawick wrote: On Fri, Oct 2, 2009 at 9:01 AM, Ricardo Cantu rica...@smartcsc.com wrote: On Friday 02 October 2009 5:35:03 am Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott barry.sc...@onelan.co.uk wrote: Is it possible to

Re: [mod_fcgid proposal] defining processing options for particular commands

Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk wrote: Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n

Re: [mod_fcgid proposal] defining processing options for particular commands

On Friday 02 October 2009 11:10:25 am Barry Scott wrote: Jeff Trawick wrote: On Fri, Oct 2, 2009 at 5:15 AM, Barry Scott barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk wrote: Jeff Trawick wrote: (instead of based on uri or vhost) FCGIDCommand

Re: incubator proposal for (what was once) Inktomi Traffic Server

Jeff Trawick wrote: On Tue, Jun 16, 2009 at 9:41 AM, Albert Lash albert.l...@gmail.com mailto:albert.l...@gmail.com wrote: +1 Speaking of code, I'd be very glad to see more C / C++ in the Apache projects. Java is fine but I think Apache went overboard with it a little.

Re: incubator proposal for (what was once) Inktomi Traffic Server

Roy T. Fielding wrote: I think this is an interesting opportunity to compare different implementations and share code where desirable. I haven't seen anyone comment on the proposal yet. +1 More code, more fun :-) Cheers Jean-Frederic

Re: incubator proposal for (what was once) Inktomi Traffic Server

+1 Speaking of code, I'd be very glad to see more C / C++ in the Apache projects. Java is fine but I think Apache went overboard with it a little. On Tue, Jun 16, 2009 at 3:19 AM, jean-frederic clerejfcl...@gmail.com wrote: Roy T. Fielding wrote: I think this is an interesting opportunity to

Re: incubator proposal for (what was once) Inktomi Traffic Server

On Tue, Jun 16, 2009 at 9:41 PM, Albert Lashalbert.l...@gmail.com wrote: Speaking of code, I'd be very glad to see more C / C++ in the Apache projects. Java is fine but I think Apache went overboard with it a little. +1

Re: incubator proposal for (what was once) Inktomi Traffic Server

Hello, On Mon, Jun 15, 2009 at 12:25 PM, Roy T. Fieldingfield...@gbiv.com wrote: I think this is an interesting opportunity to compare different implementations and share code where desirable. I haven't seen anyone comment on the proposal yet. Just out of curiosity, Flickr has been a die

Re: incubator proposal for (what was once) Inktomi Traffic Server

On Tue, Jun 16, 2009 at 9:41 AM, Albert Lash albert.l...@gmail.com wrote: +1 Speaking of code, I'd be very glad to see more C / C++ in the Apache projects. Java is fine but I think Apache went overboard with it a little. Apache is not a committee that decides what should be developed or

Re: incubator proposal for (what was once) Inktomi Traffic Server

Apache is not a committee that decides what should be developed or imposes standards like selection of implementation language or other such details. The common aspects are instead issues like governing structure, licensing, and community model.  (See http://incubator.apache.org/ and docs

Re: incubator proposal for (what was once) Inktomi Traffic Server

On Tue, Jun 16, 2009 at 10:32 AM, Albert Lash albert.l...@gmail.com wrote: Apache is not a committee that decides what should be developed or imposes standards like selection of implementation language or other such details. The common aspects are instead issues like governing structure,

Re: incubator proposal for (what was once) Inktomi Traffic Server

On Jun 16, 2009, at 10:02 AM, howard chen wrote: On Mon, Jun 15, 2009 at 12:25 PM, Roy T. Fieldingfield...@gbiv.com wrote: I think this is an interesting opportunity to compare different implementations and share code where desirable. I haven't seen anyone comment on the proposal yet. Just

Re: incubator proposal for (what was once) Inktomi Traffic Server

On Jun 15, 2009, at 12:39 PM, Pranav Desai wrote: On Sun, Jun 14, 2009 at 9:25 PM, Roy T. Fieldingfield...@gbiv.com wrote: I think this is an interesting opportunity to compare different implementations and share code where desirable. I haven't seen anyone comment on the proposal yet.

Re: incubator proposal for (what was once) Inktomi Traffic Server

This sounds awesome. Can it act as a forward proxy as well ? I guess we will find out once the source is released. Yes, YTS can be used as a forward proxy. Now that is awesome. I'm very interested now!

Re: incubator proposal for (what was once) Inktomi Traffic Server

This looks wonderful to me. I've been using Varnish and Nginx as reverse proxies a lot lately and have used mod_proxy a bunch in the past - they are all extremely useful tools and I believe there is still more room for additional tools. On Mon, Jun 15, 2009 at 12:25 AM, Roy T.

Re: incubator proposal for (what was once) Inktomi Traffic Server

On Sun, Jun 14, 2009 at 9:25 PM, Roy T. Fieldingfield...@gbiv.com wrote: I think this is an interesting opportunity to compare different implementations and share code where desirable. I haven't seen anyone comment on the proposal yet. Roy Begin forwarded message: From: Leif Hedstrom

Re: incubator proposal for (what was once) Inktomi Traffic Server

On Mon, Jun 15, 2009 at 12:06 PM, Akins, Brianbrian.ak...@turner.com wrote: On 6/15/09 12:39 PM, Pranav Desai pranavade...@gmail.com wrote: The 35000 rps is for reverse proxy or forward proxy ? Of course, I've coerced a stock mod_disk_cache/mod_proxy_http httpd server to over 40k rps on

Re: [PATCH] proposal to add interactive CGI module

+1 ;-) (for honesty sake, I asked Issac to code it, after I did a similar thing to another CGI library...) I want to add a temporary README (i.e. Executive Summary for busy people...): WHAT: A patch against module_cgi.c, that causes any apreq-based CGI program to become interactive when run by

Re: feature proposal

On Tue, 15 Mar 2005, Jie Gao wrote: Yes, there is a security concern with that setup. I can only trust X-Forwarded-For when the request is proxied from my front-end server. Which of course would then be the -ideal- place to do this access control; i.e. keep it completely out of your system.

Re: feature proposal

Jie Gao wrote: Yes, there is a security concern with that setup. I can only trust X-Forwarded-For when the request is proxied from my front-end server. In addition to DW's suggestion, mod_rewrite could easily do this type of conditional check. Really, to think of it, this feature is a bit tricky

Re: feature proposal

On Tue, 15 Mar 2005 13:25:52 +1100 (EST), Jie Gao [EMAIL PROTECTED] said: Hi All, Apache is already passing client IP addr to the backend server via a mechanism of headers: X-Forwarded-For X-Forwarded-Host X-Forwarded-Server The difficulty is that very often the backend server is an

Re: feature proposal

On Mon, 14 Mar 2005, Joshua Slive wrote: Date: Mon, 14 Mar 2005 22:20:39 -0500 From: Joshua Slive [EMAIL PROTECTED] Reply-To: dev@httpd.apache.org To: dev@httpd.apache.org Subject: Re: feature proposal On Tue, 15 Mar 2005 13:25:52 +1100 (EST), Jie Gao [EMAIL PROTECTED] said: Hi All

Re: Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...

Taking a snapshot look at the STATUS file at any given point in time does not show the actual problem. The problem is the delay in getting from point A (submitting a proposal) to point B (approval for backport). For a hot issue with many interested parties (who actually hold voting rights),

Re: Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...

On Tue, Nov 16, 2004 at 06:10:17PM -0700, Brad Nicholes wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy

Re: Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...

On Wed, Nov 17, 2004 at 10:45:14PM +, Matthieu Estrade wrote: [...] I think 2.1 is not public enough Actually, i think people don't take time to use cvs + cvs on apr and apr-util, or don't take time to find snapshot to use 2.1. They also don't telnet apache.org to look what we are

Re: Question/Proposal concerning the Apache download page

On Thu, 1 Jul 2004, Sascha Kersken wrote: Hi all, wouldn't it be a nice idea to make the http://httpd.apache.org/download.cgi script accept the name of the requested file (e.g. httpd-2.0.50.tar.gz) as path info and pass it to the automatically selected mirror? This would allow everyone to

Re: Question/Proposal concerning the Apache download page

There is another script (with the same back-end) that does almost this. See, for example: http://www.apache.org/dyn/closer.cgi/httpd/httpd-2.0.50.tar.gz Cool. Is this script linked somewhere? Or there any description out there at our site? Kess

Re: Question/Proposal concerning the Apache download page

On Thu, 1 Jul 2004, Astrid Keßler wrote: There is another script (with the same back-end) that does almost this. See, for example: http://www.apache.org/dyn/closer.cgi/httpd/httpd-2.0.50.tar.gz Cool. Is this script linked somewhere? Or there any description out there at our site?

Re: [1.3 PROPOSAL] call prctl(PR_SET_DUMPABLE)

+1 ! Jeff Trawick wrote: configure-time checks would used to check for availability (certain Linux only); the syscall would be made in the same situations as 2.x (if CoredumpDirectory has been set and we're starting as root) no patch yet, just wondering if anybody objects for some

Re: [1.3 PROPOSAL] call prctl(PR_SET_DUMPABLE)

+1 here too. It's bad enough to have a problem where we need a dump, but much worse when we can't get a dump without jumping thru hoops. Greg Jeff Trawick wrote: configure-time checks would used to check for availability (certain Linux only); the syscall would be made in the same situations

Re: [PATCH/PROPOSAL] add server_limit and thread_limit to scoreboard

On Wed, Feb 20, 2002 at 02:47:30PM -0800, Adam Sussman wrote: I know this idea isn't totaly popular, but I thought I would throw this out and see what people think. Aaron's most recent patch to the scoreboard creation logic allows you to make the apache scoreboard shared memory image

Re: [PATCH/PROPOSAL] add server_limit and thread_limit to scoreboard

On Wed, Feb 20, 2002 at 02:47:30PM -0800, Adam Sussman wrote: This patch adds the configured server_limit and thread_limit elements to the global score and sets them at the time the scoreboard is intialized. Committed, thanks! -aaron