Glenn Strauss <[EMAIL PROTECTED]> writes:
> I think your response demonstrates fairly well how obtuse input
> filtering has become. ;)
IMO ap_input_mode_t should disappear and APR_NONBLOCK_READ
should either be fixed or dumped as well. For a filter
invoked with APR_BLOCK_READ, there's nothing in
Please direct these comments to [EMAIL PROTECTED] - b.t.w., you
can check out the latest httpd-2.0 HEAD and pick up the entire proxy
solution (you must explicitly --enable-proxy-ajp and have the ajplib
sources there too.)
Someone want to take a wack at NormW's observations?
At 02:31 AM 8/11/2004,
--On Thursday, August 12, 2004 6:24 PM -0400 Glenn Strauss
<[EMAIL PROTECTED]> wrote:
Right. I didn't say it was a problem in practice.
I did say that it was a terrible piece of code, and since this list
often refers people to "look at the code", it should be fixed, IMHO.
It is a _bad_ and _brok
On Thu, Aug 12, 2004 at 02:27:03PM -0700, Justin Erenkrantz wrote:
> --On Thursday, August 12, 2004 5:03 PM -0400 Glenn Strauss
> <[EMAIL PROTECTED]> wrote:
>
> > BRIGADE_NORMALIZE skips the bucket after a 0-length bucket.
> >In doing so, it might skip a 0-length bucket following it. If the last
I would hope that 2.0 is EOLed as soon as possible after 2.2 ships.
Being basically the NetWare platform maintainer of two versions of
Apache (1.3, 2.0) with a development version on top of that, has been
bad enough. Three would be a nightmare and when would it stop? Even
for all but the most se
--On Thursday, August 12, 2004 5:03 PM -0400 Glenn Strauss
<[EMAIL PROTECTED]> wrote:
BRIGADE_NORMALIZE skips the bucket after a 0-length bucket.
In doing so, it might skip a 0-length bucket following it. If the last
IMHO, the cleanest correct fix is to just add an else clause. At the cost of
At 03:15 PM 8/12/2004, Jim Jagielski wrote:
>Geoffrey Young wrote:
>>
>> so, can someone comment on what 2.2 (and the subsequent 2.3) mean for 2.0?
>> that is, if everyday hacking is against 2.3 and we propose a new feature to
>> backport, do we backport to both 2.2 and 2.0? or does it mean that
--On Thursday, August 12, 2004 3:52 PM -0400 Glenn Strauss
<[EMAIL PROTECTED]> wrote:
I saw so much repeated code for parsing brigades, that I created a
"readahead" API: ap_brigade_ra(). It is passed similar arguments as
those to input filters, and additionally is passed a readahead struct
and a
The BRIGADE_NORMALIZE macro in server/core.c is a
terrible coding example of brigade use.
It took me a little while to wrap my head around brigades
because I had assumed this code to be correct. It is not.
BRIGADE_N
--On Thursday, August 12, 2004 4:20 PM -0400 Joshua Slive <[EMAIL PROTECTED]>
wrote:
I would hope we could make a statement like: "Major security issues will be
addressed in 2.0 until at least [2.2 release date + 1 year]."
If someone volunteers to be a 2.0 security RM, that'll happen. Otherwise,
On Thu, 12 Aug 2004, Jim Jagielski wrote:
Geoffrey Young wrote:
so, can someone comment on what 2.2 (and the subsequent 2.3) mean for 2.0?
that is, if everyday hacking is against 2.3 and we propose a new feature to
backport, do we backport to both 2.2 and 2.0? or does it mean that 2.0 has
reached
Geoffrey Young wrote:
>
> so, can someone comment on what 2.2 (and the subsequent 2.3) mean for 2.0?
> that is, if everyday hacking is against 2.3 and we propose a new feature to
> backport, do we backport to both 2.2 and 2.0? or does it mean that 2.0 has
> reached end-of-life and we backport onl
> I really think the mod_auth stuff makes it so much easier to write
> aaa backends, that we're doing a great disservice to our module writers
> by holding back on 2.2 even by a single day.
indeed :)
so, can someone comment on what 2.2 (and the subsequent 2.3) mean for 2.0?
that is, if every
I think your response demonstrates fairly well how obtuse input
filtering has become. ;)
I saw so much repeated code for parsing brigades, that I created a
"readahead" API: ap_brigade_ra(). It is passed similar arguments as
those to input filters, and additionally is passed a readahead struct
and
At 04:17 AM 8/12/2004, Mladen Turk wrote:
>Hi,
>
>Small patch that enables building against zlib-1.2.1
>instead of ancient 1.1.4 version.
Ancient? LOL - it's less than a year old due to some bugs it addressed ;-)
However, I agree with moving to 1.2.1 - with a caviat;
now that zlib1.dll is well
Hi,
> That seems rational to me. The reason for proposing [EMAIL PROTECTED]
> is so that tomcat-dev'ers wouldn't have to swallow the full bandwidth of
> [EMAIL PROTECTED] (converse of the problem where they asked anyone in [EMAIL
> PROTECTED]
> to follow [EMAIL PROTECTED] for the duration of that
--On Thursday, August 12, 2004 2:10 AM +0200 André Malo <[EMAIL PROTECTED]> wrote:
There are also some showstoppers in 2.1 which I don't see resolved until
Oct 1 or Nov 1. IIRC Nick had also a kind of roadmap (?) posted some weeks
ago.This one should also reviewed.
Well, progress isn't going to hap
At 11:19 AM 8/12/2004, Justin Erenkrantz wrote:
>--On Thursday, August 12, 2004 12:57 AM -0500 "William A. Rowe, Jr." <[EMAIL
>PROTECTED]> wrote:
>
>>Although he's subscribed to all three lists, I'd ask that they go either
>>to [EMAIL PROTECTED] or [EMAIL PROTECTED] The history of the discussions
--On Thursday, August 12, 2004 2:51 AM -0400 Glenn Strauss
<[EMAIL PROTECTED]> wrote:
/** The filter should pass any special buckets (not in-memory) as long
as it * does not need to perform any processing on them (translation
or protocol * delimiting) (augments AP_MODE_BYTES; mutu
--On Thursday, August 12, 2004 12:57 AM -0500 "William A. Rowe, Jr."
<[EMAIL PROTECTED]> wrote:
Although he's subscribed to all three lists, I'd ask that they go either
to [EMAIL PROTECTED] or [EMAIL PROTECTED] The history of the discussions is just
as important as the actual code commits.
Can w
Bill Stoddard wrote:
Mladen Turk wrote:
Hi,
Small patch that enables building against zlib-1.2.1
instead of ancient 1.1.4 version.
Are there any compelling reasons to move from 1.1.4 to 1.2.1? Just
curious and no time to investigate for myself right at the moment.
As stated on the official zlib
Mladen Turk wrote:
Hi,
Small patch that enables building against zlib-1.2.1
instead of ancient 1.1.4 version.
Are there any compelling reasons to move from 1.1.4 to 1.2.1? Just curious and no time to investigate for
myself right at the moment.
Bill
Paul Querna wrote:
My basic question for the list is, are we better off modifying
the Worker MPM, or should we create a new 'event' MPM for now?
My $.02 worht:
Make an event MPM that is experimental. That way people can use "tried
and true" worker, or try the fancy new event one.
--
Brian Aki
On Wed, Aug 11, 2004 at 12:08:40PM -0500, William A. Rowe, Jr. wrote:
>
> One thought on 2.2 was to simply not place any unfinished modules on that
> branch, and let them live on in the 2.1-dev (well, that becomes 2.3-dev once
> 2.2.0 is golden), until it can be released. The modules can live in
Hi all,
To be able to use the new proxy balancer to it's full
potential we need some sort of dynamic configuration.
The typical scenarios are:
a) Mark a node(s) as 'disabled' for maintenance.
b) Add an extra node(s) for additional load.
c) Change the load factors.
At first I was thinking to add tha
Hi,
Small patch that enables building against zlib-1.2.1
instead of ancient 1.1.4 version.
Index: mod_deflate.dsp
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_deflate.dsp,v
retrieving revision 1.10
diff -u -r1.10 mod_def
On Thu, Aug 12, 2004 at 10:29:54AM +0200, Jos Dehaes wrote:
> This works, but we don't have access to the cert chain when our callback
> is called (SSL_get_peer_cert_chain returns a NULL pointer). Is this
> normal (not yet filled in)? Or do we use the wrong callback/hook at the
> wrong place?
I th
Hello,
we would like to do our own verification of client certificates, and to
that effect have written a module and a patch to mod_ssl that replaces
the verify callback with our own hook in ssl_hook_Access
(ssl_engine_kernel.c):
APR_OPTIONAL_FN_TYPE(custom_ssl_verify) *cust_verify = NULL;
cust_
28 matches
Mail list logo
