httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the DocumentRoot (e.g.,
On Wed, 4 Sep 2002 10:38:18 -0700
Justin Erenkrantz [EMAIL PROTECTED] wrote:
[...]
[...] What if there's no command line
options, but only plain config file? I think we schould do as
listed:
Yeah, APR should have all of the getopt bits already available.
But, I would definitely prefer
On Wed, 4 Sep 2002 10:47:14 -0700
Aaron Bannert [EMAIL PROTECTED] wrote:
On Wed, Sep 04, 2002 at 10:29:54AM -0700, Justin Erenkrantz wrote:
I think we actually tagged 1.0 when we were doing the OSCON
presentation, but we never released it.
Yeah, we already tagged FLOOD_1_0, so let's put
On Thu, Sep 05, 2002 at 05:29:26PM +0200, Jacek Prucia wrote:
- fix install target so we can install flood amd examples off $SRCDIR
- fix few more bugs from STATUS (I'm on it)
- move tag on changed files and roll tarball
I'm ok with whatever anyone else does, since the three of us
are the
On Wed, Sep 04, 2002 at 10:43:51AM -0700, Justin Erenkrantz wrote:
...and react to WWW-Authenticate header just like browsers and other
tiny clients (like wget) do. And I think we want to mimic browser
behaviour. OTOH this brings up other issue -- an url list where we can
insert new urls
On 5 Sep 2002 [EMAIL PROTECTED] wrote:
bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
+if (bb == NULL) {
+r-connection-keepalive = AP_CONN_CLOSE;
+return -1;
+}
apr_brigade_create() will never return NULL. This bit is unnecessary.
Cliff Woolley wrote:
On 5 Sep 2002 [EMAIL PROTECTED] wrote:
bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
+if (bb == NULL) {
+r-connection-keepalive = AP_CONN_CLOSE;
+return -1;
+}
apr_brigade_create() will never return NULL. This
On Wed, 4 Sep 2002, Brian Pane wrote:
That's not guaranteed. The API, as currently documented, only
guarantees that it will return an apr_bucket_brigade*, not that
it will be non-null.
It's non-null as long as apr_palloc returns non-null. Which it is. In
other words, it is part of the
Cliff Woolley wrote:
On Wed, 4 Sep 2002, Brian Pane wrote:
That's not guaranteed. The API, as currently documented, only
guarantees that it will return an apr_bucket_brigade*, not that
it will be non-null.
It's non-null as long as apr_palloc returns non-null. Which it is. In
other
Hi,
I've recompiled the server with only the proxy and the core modules :
Compiled in modules:
core.c
mod_proxy.c
proxy_connect.c
proxy_ftp.c
proxy_http.c
prefork.c
http_core.c
But the problem remains :
[Thu Sep 05 10:04:55 2002] [info] (32)Broken pipe: core_output_filter:
On Tue, Sep 03, 2002 at 09:51:20AM -0500, Jess M. Holle wrote:
It would be nicest of all to have builds of each version of the core for
each platform -- and pluggable binaries of all the extra modules for
each version/platform as well.
Eergh.. this sounds like a maintenance nightmare.
On Tue, Sep 03, 2002 at 06:59:38PM -0400, [EMAIL PROTECTED] wrote:
Can I ask a stupid question? What have we actually broken since Apache
2.0 went GA? Binary compatibility? How many functions? How many of
those were APR and not Apache?
Sure, both source and binary compatibility
Peter Van Biesen wrote:
Does anybody have another idea for me to try ?
Have you tried the latest fix for the client_block stuff, I think I saw
a very recent CVS checkin...?
There could of course be more than one leak, and we'll only fix the
problem once all of them are found...
Regards,
Ian Holsman wrote:
[EMAIL PROTECTED] wrote:
jerenkrantz2002/09/05 00:31:14
Modified:.CHANGES
modules/http mod_mime.c
Log:
Add ModMimeUsePathInfo directive.
+int use_path_info;/* If set to 0, only use filename.
+
Hmm. We might not even need the fixup. Now that *every* handler is executed
nowadays, we can probably just remove the concept of dav-handler and move
those checks in type_checker/fixups into dav_handler() itself.
Hmm. Perhaps. I'll take a look at it. -- justin
Small problem with
(this discussion assumes Apache has IPv6 capability)
There are some situations during normal web server operation where
resolver calls are made to find addresses associated with names and we
have no clue whether or not the name has an IPv6 address associated with
it. Forward proxy is a good
On Thu, Sep 05, 2002 at 06:43:52AM -0700, Ian Holsman wrote:
-1
don't use magic numbers
please use a #define
Sorry, but the rest of the server uses this strategy for flags.
Look specifically at IdentityCheck and ContentDigest.
The problem is that the AP_INIT_FLAG and ap_set_flag_slot passes
Peter Van Biesen wrote:
Hi,
I've recompiled the server with only the proxy and the core modules :
But the problem remains :
Does anybody have another idea for me to try ?
There was a fix for http_protocol.c last night that addressed
at least one problem that could cause the proxy to run
Graham Leggett [EMAIL PROTECTED] writes:
Peter Van Biesen wrote:
Does anybody have another idea for me to try ?
Have you tried the latest fix for the client_block stuff, I think I saw
a very recent CVS checkin...?
There could of course be more than one leak, and we'll only fix the
On Thu, Sep 05, 2002 at 11:14:42AM -0400, Ryan Bloom wrote:
Hmm. We might not even need the fixup. Now that *every* handler is executed
nowadays, we can probably just remove the concept of dav-handler and move
those checks in type_checker/fixups into dav_handler() itself.
Hmm.
aaa rewrite belongs in:
2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick,
ianh, gs, bnicholes
2.1: dpejesh, chris, aaron, hb
If someone would like to do a release before I check in the aaa
changes, I'd be game to hold off until Monday or Tuesday.
(I don't have the time to
On Thu, Sep 05, 2002 at 04:26:22PM -0700, Justin Erenkrantz wrote:
aaa rewrite belongs in:
2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick,
ianh, gs, bnicholes
2.1: dpejesh, chris, aaron, hb
If someone would like to do a release before I check in the aaa
changes,
On Thu, 5 Sep 2002, Aaron Bannert wrote:
On Thu, Sep 05, 2002 at 04:26:22PM -0700, Justin Erenkrantz wrote:
aaa rewrite belongs in:
2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick,
ianh, gs, bnicholes
2.1: dpejesh, chris, aaron, hb
If someone would like to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Given this argument, might I suggest doing a release before these AAA
changes are started, then at least all of the patches between 2.0.40
and now can be made GA?
Also gives more time before the public start wondering where things
are (if the AAA
On Thu, Sep 05, 2002 at 04:41:38PM -0700, Marc Slemko wrote:
The argument would be that they would never be stabilized until they
are in HEAD since few people will use them until then.
And my counter argument is that it doesn't really matter if nobody
uses it until it makes it into HEAD. This
+1 for this and apache wide config flag.
david
(this discussion assumes Apache has IPv6 capability)
There are some situations during normal web server operation where
resolver calls are made to find addresses associated with names and we
have no clue whether or not the name has an IPv6
On Thu, Sep 05, 2002 at 04:51:56PM -0700, Aaron Bannert wrote:
...
We can make a branch for a security release after the fact, either
off the last release or off the pre-auth-change tag and then build
a security-fix-only release off that branch.
Why would we branch for a security fix in
On Thu, Sep 05, 2002 at 04:26:22PM -0700, Justin Erenkrantz wrote:
aaa rewrite belongs in:
2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick,
ianh, gs, bnicholes
2.1: dpejesh, chris, aaron, hb
If someone would like to do a release before I check in the aaa
changes,
On Thu, Sep 05, 2002 at 05:22:49PM -0700, Greg Stein wrote:
I'll try to get the release done over the weekend. Hell... at least a tag.
Given a tag, then you can do whatever the heck you want.
This is fair as long as it doesn't unreasonably disrupt anyelse's ability
to work on whatever they
On Thu, Sep 05, 2002 at 05:21:34PM -0700, Greg Stein wrote:
Quite simple, actually. You put the developers in definite pain by making
them branch, compared to a *potential* pain of a branch for a security fix.
pain being arguable, of course -- it all depends upon people's aversion to
CVS
Joe Schaefer wrote:
There's also a refcount problem in http_protocol.c wrt chunked
transfer codings. The problem is that the bucket holding the
chunk size isn't ever freed, so the corresponding data block
is overcounted.
Here's a diff for http_protocol.c against current anon-cvs (which
doesn't
David Hill wrote:
Hi all,
I am seeing log messages saying the listener thread didn't exit. This
is coming out of the housekeeping stuff in the worker module. I am using
2.0.40 and Tru64. I *think* it is happening when the server is trying to
reduce surplus clients.
The worker MPM has known
Jeff Trawick wrote:
(this discussion assumes Apache has IPv6 capability)
There are some situations during normal web server operation where
resolver calls are made to find addresses associated with names and we
have no clue whether or not the name has an IPv6 address associated with
it.
33 matches
Mail list logo
