Brad Nicholes wrote:
-1 as well. This is now causing compiler errors on NetWare. Please
revert this patch!
Can you provide an indication of exactly what broke so we
will know what to avoid in future. Or was the breakage
actually due to the the mod_cache problem reported
last night?
Thanks, Allan
mod_cache is a different issue. The compiler used to build the
netware NLMs is very sensitive to type mismatches.
@@ -3793,7 +3794,7 @@
core_net_rec *net = f-ctx;
core_ctx_t *ctx = net-in_ctx;
const char *str;
-apr_size_t len;
+apr_ssize_t len;
whoa! -1
Was this even discussed on the list? You just changed the
entire module API and introduced a dozen potential security holes.
Why on earth is it changing nvec to apr_size_t and then downcasting
its use? Why is any of this even needed?
Roy
On Oct 22, 2004, at 8:22 AM, [EMAIL
Roy T. Fielding wrote:
whoa! -1
Was this even discussed on the list? You just changed the
entire module API and introduced a dozen potential security holes.
The precursor to this patch [PATCH] WIN64: httpd API changes
was posted 10/7 so I thought we had had suitable time for
discussion. I have
The precursor to this patch [PATCH] WIN64: httpd API changes
was posted 10/7 so I thought we had had suitable time for
discussion. I have addressed the one issue that was raised.
That explains why I didn't see it -- I was in Switzerland.
There have also been several other threads on the httpd apr
Roy is right...
Willy-nilly throwing casts on data objects just to satisfy some
anal-retentive urge to not see any warnings appearing during a
compile is the absolute WRONG thing to do when it comes
to porting 32-bit code to 64-bit platforms.
The situation is NOT as simple as it was when
[EMAIL PROTECTED] wrote:
jorton 2004/05/17 08:24:31
Modified:server core.c
Log:
* server/core.c (core_output_filter): Don't explicitly delete the EOC
bucket, and don't buffer the brigade if it ends in an EOC.
Won't this change result in a memory leak?
Bill
On Mon, May 17, 2004 at 01:06:04PM -0400, Bill Stoddard wrote:
[EMAIL PROTECTED] wrote:
jorton 2004/05/17 08:24:31
Modified:server core.c
Log:
* server/core.c (core_output_filter): Don't explicitly delete the EOC
bucket, and don't buffer the brigade if it ends in an EOC.
[EMAIL PROTECTED] wrote:
nd 2004/04/10 11:40:53
Modified:server core.c
Log:
ErrorDocument default changes broke inheritance. consider:
Directory /foo
ErrorDocument 404 blah
/Directory
DIrectory /foo/bar
ErrorDocument 500 boo
# 404 is now fallen
On Sat, 10 Apr 2004 [EMAIL PROTECTED] wrote:
nd 2004/04/10 14:44:43
Modified:.CHANGES
server core.c
Log:
accept URLs as ServerAdmin contact. If it's not recognized as an URL, assume
an email address and prepend it with mailto: in server
* Joshua Slive [EMAIL PROTECTED] wrote:
Modified:.CHANGES
server core.c
Log:
accept URLs as ServerAdmin contact. If it's not recognized as an URL,
assume an email address and prepend it with mailto: in server outputs.
Careful with this, since I
[EMAIL PROTECTED] wrote:
geoff 2004/04/08 17:56:26
Modified:.CHANGES
server core.c
Log:
Enable special ErrorDocument value 'default' which restores the
canned server response for the scope of the directive.
if this stays in 2.1 it will need
On Thu, 8 Apr 2004, Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
geoff 2004/04/08 17:56:26
Modified:.CHANGES
server core.c
Log:
Enable special ErrorDocument value 'default' which restores the
canned server response for the scope of the
Just edit the .xml. (There is a big ugly note at the top of the .html.en
telling you not to touch it.) Then you can build the .html.en using
the instructions here:
http://httpd.apache.org/docs-project/docsformat.html
Or if you don't want to bother, just do the .xml and someone else will
Uhmmm, this isn't an MMN bump :) If you were adding this new
structure *type* as a member of another structure (say as the last
member of the conn_rec) and the structure grew (in such a way that
folks could be blindly oblivious to the fact that conn_rec just got a
bit bigger), that's an MMN bump.
On Tue, 3 Feb 2004, William A. Rowe, Jr. wrote:
Uhmmm, this isn't an MMN bump :) If you were adding this new
structure *type* as a member of another structure (say as the last
member of the conn_rec) and the structure grew (in such a way that
folks could be blindly oblivious to the fact that
* Cliff Woolley [EMAIL PROTECTED] wrote:
On Tue, 3 Feb 2004, William A. Rowe, Jr. wrote:
Uhmmm, this isn't an MMN bump :) If you were adding this new
structure *type* as a member of another structure (say as the last
member of the conn_rec) and the structure grew (in such a way that
[EMAIL PROTECTED] wrote:
trawick 2003/12/10 14:40:33
Modified:.CHANGES
server core.c
Log:
Fix Limit and LimitExcept parsing to require a closing ''
in the initial container.
PR:25414
Submitted by: Geoffrey Young
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 3:25 AM
striker 2003/06/30 18:25:07
Modified:.Tag: APACHE_2_0_BRANCH CHANGES STATUS
include Tag: APACHE_2_0_BRANCH http_core.h
modules/http Tag:
William A. Rowe, Jr. wrote:
The configuration and context below seems odd to me;
:
You haven't resolved any Directory, Files, Locations etc in the
code fragment above... it's too early in the request processing cycle.
It seems this should not be a dir_conf flag, but actually a
coar2003/01/23 13:34:14
Modified:include ap_mmn.h http_core.h httpd.h
server core.c request.c util.c
Log:
here we go. add a directive that will keep %2f from being
decoded into '/', allowing the *_walk to do their magic and
return 404 if
* [EMAIL PROTECTED] wrote:
Index: ap_mmn.h
===
RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -u -r1.52 -r1.53
--- ap_mmn.h3 Sep 2002 23:39:43
* Justin Erenkrantz wrote:
--On Friday, January 24, 2003 00:11:22 +0100 André Malo [EMAIL PROTECTED]
wrote:
+ * 20020903.1 (2.0.44-dev) allow_encoded_slashes added to
core_dir_config
This should now be 2.0.45-dev, shouldn't it?
2.1.0-dev. -- justin
*err* yes ...
nd
--
die (eval
[EMAIL PROTECTED] wrote:
gregames2002/12/09 14:19:26
Modified:.CHANGES
server core.c
Log:
core_output_filter: re-instate the deferred_write pool patch so we don't
leak fd's until the end of a keepalive connection.
Thanks to:
Jeff Trawick for the
On Wed, 8 Jan 2003, Greg Ames wrote:
Can I get some +1's for moving this into stable (or -1's and reasons not
to do so)?
- Its one month birthday is tomorrow,
- it is certainly in mainline code, and
- AFAIK it hasn't caused any problems since the apr_mmap ownership redesign.
+1 from here
[EMAIL PROTECTED] wrote:
can't mix declarations and statements except with gcc 3.2 :)
(or possibly RedHat 8's patches to it)
ouch...
Thanks for cleaning it up, Jeff.
Greg
[EMAIL PROTECTED] wrote:
trawick 2002/11/08 05:17:09
Modified:server core.c
Log:
adjust some parents to make the expression a tiny bit clearer and to
make gcc happy
core.c: In function `core_output_filter':
core.c:3884: warning: suggest parentheses around within ||
On Wed, Oct 02, 2002 at 03:54:18PM -0700, Joshua Slive wrote:
On Wed, 2 Oct 2002, Marc Slemko wrote:
Lets not encode env variables, as we discussed earlier.
Escaping them is bogus and doesn't solve anything since there are all
sorts of variables that aren't and shouldn't be encoded.
* Joe Orton wrote:
If this change does get reverted so that SERVER_NAME is not encoded
internally again, the error includes need updating so that is is
encoded there instead:
--- error/include/bottom.html~ 2002-07-11 20:07:03.0 +0100
+++ error/include/bottom.html 2002-10-09
On Wed, 2 Oct 2002, Marc Slemko wrote:
Lets not encode env variables, as we discussed earlier.
Escaping them is bogus and doesn't solve anything since there are all
sorts of variables that aren't and shouldn't be encoded.
+1 to what Marc says. The encoding serves no purpose. Preventing
If someone reverts that -part- of the commit, and changes CHANGES
to reflect this group decision, I will bring in that commit tomorrow a.m.
before the final tag and roll.
Sorry if I wasn't clear on the consensus decision. +1.
Bill
At 05:54 PM 10/2/2002, Joshua Slive wrote:
On Wed, 2 Oct
On 1 Oct 2002 [EMAIL PROTECTED] wrote:
gstein 2002/10/01 09:24:41
Modified:server core.c
Log:
Fix bug in the default handler. POST is not allowed on regular files.
The resource must be handled by something *other* than the default
handler.
-1. This is going to
[EMAIL PROTECTED] wrote:
jerenkrantz2002/06/26 22:00:23
Modified:server core.c
Log:
- Fix segfault in core_output_filter when we are passed an empty brigade.
- Stash the remainder of the brigade in more when we see a flush bucket.
Previous to this commit, we would only
On Wed, Jun 26, 2002 at 10:20:56PM -0700, Brian Pane wrote:
Do you have a simple test case for this? I'd like to add it it
to httpd-test.
You already have one. =)
mod_bucketeer's test portion in include.t caught it. They are now
passing for me.
Horray for mod_bucketeer... -- justin
[EMAIL PROTECTED] writes:
jerenkrantz2002/06/26 12:45:08
Modified:.CHANGES
include ap_mmn.h httpd.h
modules/arch/win32 mod_isapi.c
modules/http http_core.c http_protocol.c http_request.c
modules/loggers
On 15 Jun 2002 [EMAIL PROTECTED] wrote:
rbb 2002/06/14 22:49:06
Modified:.CHANGES
server core.c
Log:
Make the default_handler catch all requests that aren't served by
another handler. This also gets us to return a 404 if a directory
is
On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
...
Ok, segfault is gone. So is some validation that ServerRoot occured in a
global
context. Actually, that means that LoadModule and others are not tested to be
in the global context either.
(see further below)
...
On Mon, 20 May 2002, Greg Stein wrote:
On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
On Win32, we load-unload-reload the parent, then load-unload-reload
the child config. Losing both redundant unload-load sequences will
be a huge win at startup.
Yup. If we
At 07:31 PM 5/20/2002, Scott Hess wrote:
On Mon, 20 May 2002, Greg Stein wrote:
On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
On Win32, we load-unload-reload the parent, then load-unload-reload
the child config. Losing both redundant unload-load sequences will
On 18 May 2002 [EMAIL PROTECTED] wrote:
to work around problematic configs. So I'm reverting those changes,
for now.
Thanks.
ServerRoot is global only, and it MUST be read immediately, so that
part of the last patch stays.
Mmm, nope, sorry, but that one has to go, too.
wrowe 02/05/18 10:22:24
Modified:server core.c
Log:
Resolve the EXEC_ON_READ bit for ServerRoot and other modules that test
the directive context. Should eliminate the segfault.
Ok, segfault is gone. So is some validation that ServerRoot occured in a
global
At 12:19 PM 5/18/2002, you wrote:
On 18 May 2002 [EMAIL PROTECTED] wrote:
to work around problematic configs. So I'm reverting those changes,
for now.
Thanks.
ServerRoot is global only, and it MUST be read immediately, so that
part of the last patch stays.
Mmm, nope,
On Sat, 18 May 2002, William A. Rowe, Jr. wrote:
ServerRoot is global only, and it MUST be read immediately, so that
part of the last patch stays.
Mmm, nope, sorry, but that one has to go, too.
No, it has to stay.
However, I think I have an adaquate solution in the last
On 17 May 2002 [EMAIL PROTECTED] wrote:
wrowe 02/05/17 12:34:53
Modified:server core.c
Log:
We need to grab ServerRoot, LogLevel, and ErrorLog right off the bat
as we are reading the config.
This closes a bug where ServerRoot /foo + LoadModule
Jeff Trawick wrote:
+AP_DECLARE(void) ap_setup_make_content_type(apr_pool_t *pool);
What's up with this? This has to go in a header file included by both
core.c and protocol.c.
It's fixed now (I moved the declaration to http_protocol.h and
wrapped it in #ifdef CORE_PRIVATE)
--Brian
Roy T. Fielding wrote:
I don't understand why you didn't simply reverse the test and
enclose the frequent case inside the if {} block.
D'oh! of course! commit coming shortly.
I assume it
was just to avoid indenting a large block of code, which is not
sufficient
I don't understand why you didn't simply reverse the test and
enclose the frequent case inside the if {} block. I assume it
was just to avoid indenting a large block of code, which is not
sufficient justification for a goto.
A goto often has unforeseen effects on high-level optimizations
that
Bill Stoddard wrote:
Please lets not go overboard with these types of optimizations. This could get out
of
control quickly. Having code that is easy to read, understand and maintain is -much-
more
important than saving a a few extra cycles.
In a previous job where I had a lot of low
Bill Stoddard wrote:
Please lets not go overboard with these types of optimizations. This could get
out of
control quickly. Having code that is easy to read, understand and maintain is
-much-
more
important than saving a a few extra cycles.
In a previous job where I had a lot of low
Please lets not go overboard with these types of optimizations. This could get out of
control quickly. Having code that is easy to read, understand and maintain is -much-
more
important than saving a a few extra cycles.
Bill
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL
On Wed, Apr 24, 2002 at 02:31:29PM -, [EMAIL PROTECTED] wrote:
gregames02/04/24 07:31:28
Modified:server core.c
Log:
default_handler: short circuit the method checks. Move the code to deal
with unusual methods to the end of function to reduce i-cache clutter.
Can't
Greg,
Please do not mix function change with code style changes.
Bill
gregames02/03/05 07:46:21
Modified:server core.c
Log:
fix Directory ~ blah containers.
also, eradicate a few nefarious tabs which were found lurking in the vicinity.
Submitted by: Rob
On Mon, Mar 04, 2002 at 09:20:03AM -, [EMAIL PROTECTED] wrote:
jerenkrantz02/03/04 01:20:03
Modified:server core.c
Log:
Ensure that net_time filter isn't added on subreqs - we assume that it is
added on !r-main requests. This led to infinite loop/SEGV when dealing
I now have two further problems
1) Since fast_redirect() is called from a hook, but all hooks are run
on this new request - it is possible that some hooks are left to
be run from the original request This causes a problem for the
AddOutputFilterByType hook (core_filters_type) since it is
On Mon, Mar 04, 2002 at 07:07:03AM -0800, Ryan Bloom wrote:
I now have two further problems
1) Since fast_redirect() is called from a hook, but all hooks are run
on this new request - it is possible that some hooks are left to
be run from the original request This causes a problem for
Ryan Bloom wrote:
I don't care how de-stabilized the code base becomes.
That's a very alarming thing to read.
Making perchild work is one thing. Warping, or even just tweaking,
common code in order to make perchild work is something else
again.
--
#kenP-)}
Ken Coar,
Ryan Bloom wrote:
I don't care how de-stabilized the code base becomes.
That's a very alarming thing to read.
Making perchild work is one thing. Warping, or even just tweaking,
common code in order to make perchild work is something else
again.
If you read the statement in
Ryan Bloom wrote:
I also disagree that just tweaking common code should be a problem.
Perhaps most importantly though, I don't think the changes for perchild
will extend beyond the MPM.
That's cool, then. However, it *does* seem that recently (last
few months) there tends to be a lot of
On Tue, 26 Feb 2002, Rodent of Unusual Size wrote:
| Unlike others here, I'm not emotionally invested in getting 2.0
| out soon. If it takes a few more months for it to be Ready,
| that's fine with me. I think there are some interested parties
| that would rather have it released sooner than
Dale Ghent wrote:
On Tue, 26 Feb 2002, Rodent of Unusual Size wrote:
| Unlike others here, I'm not emotionally invested in getting 2.0
| out soon. If it takes a few more months for it to be Ready,
| that's fine with me. I think there are some interested parties
| that would rather have it
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
+
+* With AP_MODE_EXHAUSTIVE in the core, it is finally clear to
me
+ how the Perchild MPM should be re-written. It hasn't worked
+ correctly since filters were added because it wasn't
possible to
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE
UP:
+
+* With AP_MODE_EXHAUSTIVE in the core, it is finally clear
to
me
+ how the Perchild MPM should be re-written. It hasn't
worked
+ correctly since filters were added because it wasn't
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE
UP:
+
+* With AP_MODE_EXHAUSTIVE in the core, it is finally clear to
me
+ how the Perchild MPM should be re-written. It hasn't
worked
+ correctly since filters were added because it wasn't
possible to
+
On Sun, Feb 24, 2002 at 11:29:30PM -0800, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
+
+* With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me
+ how the Perchild MPM should be re-written. It hasn't
On Sun, 24 Feb 2002, Brian Pane wrote:
[EMAIL PROTECTED] wrote:
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
+
+* With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me
+ how the Perchild MPM should be re-written. It hasn't worked
+
Ryan Bloom wrote:
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
+
+* With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me
+ how the Perchild MPM should be re-written. It hasn't worked
+ correctly since filters were added because it wasn't possible
I agree that documentation should cover this, but it should also be
displayed in the ./configure if someone chooses that, to say, display a
warning at the end of the configure or some such thing.
At least there'd be an I told you so in there.
On Mon, 2002-02-25 at 19:31, Joshua Slive wrote:
[EMAIL PROTECTED] wrote:
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
+
+* With AP_MODE_EXHAUSTIVE in the core, it is finally clear to me
+ how the Perchild MPM should be re-written. It hasn't worked
+ correctly since filters were added because it
On 21 Feb 2002 [EMAIL PROTECTED] wrote:
e = apr_bucket_file_create(fd, 0, AP_MAX_SENDFILE, r-pool);
while (fsize AP_MAX_SENDFILE) {
-APR_BRIGADE_INSERT_TAIL(bb, e);
-apr_bucket_copy(e, e);
+apr_bucket *ce;
+
From: Cliff Woolley [EMAIL PROTECTED]
Sent: Thursday, February 21, 2002 12:28 PM
On 21 Feb 2002 [EMAIL PROTECTED] wrote:
e = apr_bucket_file_create(fd, 0, AP_MAX_SENDFILE, r-pool);
while (fsize AP_MAX_SENDFILE) {
-APR_BRIGADE_INSERT_TAIL(bb, e);
On Thu, 21 Feb 2002, Cliff Woolley wrote:
At first I thought this was giving a duplicate copy of the first bucket,
but then I realized that by moving the INSERT call down, you've avoided
that problem. However, aren't we leaking e?
Oh, I see it. Nevermind. Sometimes I wish diff -u would
[EMAIL PROTECTED] writes:
jerenkrantz02/02/18 20:45:53
Modified:.CHANGES
include ap_mmn.h http_core.h
server core.c
Log:
Introduce AddOutputFilterByType directive.
AddOutputFilterByType DEFLATE text/html
Why does this warrant
On Tue, Feb 19, 2002 at 12:52:01PM -0500, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
jerenkrantz02/02/18 20:45:53
Modified:.CHANGES
include ap_mmn.h http_core.h
server core.c
Log:
Introduce AddOutputFilterByType
On Tue, Feb 19, 2002 at 12:52:01PM -0500, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
jerenkrantz02/02/18 20:45:53
Modified:.CHANGES
include ap_mmn.h http_core.h
server core.c
Log:
Introduce AddOutputFilterByType
On Tue, Feb 19, 2002 at 03:25:23PM -0800, Ryan Bloom wrote:
Core_dir_config should be a private structure, so it doesn't require a
MMN bump.
Just looking at when MMN has been bumped before, it looks like almost
all changes to core_dir_config have been followed by MMN bump. Why
have people
From: [EMAIL PROTECTED]
Sent: Monday, February 18, 2002 10:45 PM
jerenkrantz02/02/18 20:45:53
Modified:.CHANGES
include ap_mmn.h http_core.h
server core.c
Log:
Introduce AddOutputFilterByType directive.
AddOutputFilterByType
On Wed, Feb 06, 2002 at 04:16:55PM -, [EMAIL PROTECTED] wrote:
trawick 02/02/06 08:16:55
Modified:server core.c
Log:
yet another tweak to empty brigade checking on entry to core_input_filter():
since APR_BRIGADE_EMPTY() assumes a non-empty brigade, we have to
On Wed, 6 Feb 2002, Justin Erenkrantz wrote:
You mean APR_BRIGADE_NORMALIZE assumes a non-empty brigade,
right? -- justin
Yeah... must have been a typo. Boy do I hate normalize... makes me need
another cup of coffee just thinking about it. :)
Normalize is definitely next on my hitlist.
Justin Erenkrantz [EMAIL PROTECTED] writes:
On Wed, Feb 06, 2002 at 04:16:55PM -, [EMAIL PROTECTED] wrote:
trawick 02/02/06 08:16:55
...
An obvious variation of this fix would be to change APR_BRIGADE_NORMALIZE()
to deal with empty brigades.
You mean APR_BRIGADE_NORMALIZE
Justin Erenkrantz [EMAIL PROTECTED] writes:
On Tue, Feb 05, 2002 at 10:56:44PM -, [EMAIL PROTECTED] wrote:
trawick 02/02/05 14:56:44
Modified:.CHANGES
server core.c
Log:
In core_input_filter, check for an empty brigade after
I suspect something is messed up in your build. f-ctx (and net-c) are both
initialized
in the core_install_transport_filters(conn_rec *c, apr_socket_t *csd) call. It compiles
and serves pages cleanly for me. Can you verify if core_install_transport_filters is
being
run?
Bill
[EMAIL
Bill Stoddard [EMAIL PROTECTED] writes:
I suspect something is messed up in your build.
never :) (seriously... I spend most of my day watching make
extraclean scroll by... even after a config file change)
All I gotta say is:
#0 core_output_filter (f=0x40615fec, b=0x405ddff4) at
Bill Stoddard [EMAIL PROTECTED] writes:
I suspect something is messed up in your build. f-ctx (and net-c) are both
initialized
in the core_install_transport_filters(conn_rec *c, apr_socket_t *csd) call. It
compiles
and serves pages cleanly for me. Can you verify if
Message -
From: Jeff Trawick [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 29, 2002 9:54 PM
Subject: Re: cvs commit: httpd-2.0/server core.c
Bill Stoddard [EMAIL PROTECTED] writes:
I suspect something is messed up in your build. f-ctx (and net-c) are both
initialized
Bill Stoddard [EMAIL PROTECTED] writes:
Compiles but not tested.
it works for me...
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Bill Stoddard [EMAIL PROTECTED] writes:
Compiles but not tested.
it works for me...
Just tested it on Windows. Bombs w/o the patch. Ok with. Committing.
Bill
On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
This patch breaks the proxy. Specifically, anyone who uses
ap_proxy_make_fake_req(). Get
a seg fault in ap_get_limit_req_body because r-per_dir_config is NULL. I'll
spend
some
time on this tomorrow unless someone wants
On Thursday 03 January 2002 05:16 am, Bill Stoddard wrote:
On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
This patch breaks the proxy. Specifically, anyone who uses
ap_proxy_make_fake_req(). Get
a seg fault in ap_get_limit_req_body because r-per_dir_config is NULL.
Here is the problem with this patch... (or with proxy's use of HTTP_IN)...
ap_http_filter is called to read -responses- from the proxied server. This patch makes
an
implicit assumption that HTTP_IN is only being used to read requests. So, we either
need
to create a whole new filter stack for
On Thursday 03 January 2002 09:50 am, Bill Stoddard wrote:
Here is the problem with this patch... (or with proxy's use of HTTP_IN)...
ap_http_filter is called to read -responses- from the proxied server. This patch
makes an
implicit assumption that HTTP_IN is only being used to read
From: Ryan Bloom [EMAIL PROTECTED]
Sent: Thursday, January 03, 2002 10:14 AM
On Thursday 03 January 2002 05:16 am, Bill Stoddard wrote:
Is it valid for r-per_dir_config to be null? Hmm. I wonder if
ap_get_limit_req_body should be fixed to handle this case instead
of
From: Ryan Bloom [EMAIL PROTECTED]
Sent: Thursday, January 03, 2002 10:14 AM
On Thursday 03 January 2002 05:16 am, Bill Stoddard wrote:
Is it valid for r-per_dir_config to be null? Hmm. I wonder if
ap_get_limit_req_body should be fixed to handle this case instead
of
On Thu, Jan 03, 2002 at 02:31:49PM -0500, Bill Stoddard wrote:
I've spent some time on this and this is one reason I am sort of interested in a
proxy
specific input filter. I agree with Ryan that 99.9% would be identical to what is
already
in HTTP_IN now.
Then, why have a separate input
On Thu, Jan 03, 2002 at 02:31:49PM -0500, Bill Stoddard wrote:
I've spent some time on this and this is one reason I am sort of interested in a
proxy
specific input filter. I agree with Ryan that 99.9% would be identical to what is
already
in HTTP_IN now.
Then, why have a separate
This patch breaks the proxy. Specifically, anyone who uses ap_proxy_make_fake_req().
Get
a seg fault in ap_get_limit_req_body because r-per_dir_config is NULL. I'll spend
some
time on this tomorrow unless someone wants to jump on it tonight.
Bill
- Original Message -
From: [EMAIL
On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
This patch breaks the proxy. Specifically, anyone who uses
ap_proxy_make_fake_req(). Get
a seg fault in ap_get_limit_req_body because r-per_dir_config is NULL. I'll spend
some
time on this tomorrow unless someone wants to jump
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Wednesday, January 02, 2002 4:15 PM
On Wed, Jan 02, 2002 at 05:15:34PM -0500, Bill Stoddard wrote:
This patch breaks the proxy. Specifically, anyone who uses
ap_proxy_make_fake_req(). Get
a seg fault in ap_get_limit_req_body because
From: Bill Stoddard [EMAIL PROTECTED]
Sent: Wednesday, January 02, 2002 4:15 PM
This patch breaks the proxy. Specifically, anyone who uses
ap_proxy_make_fake_req(). Get
a seg fault in ap_get_limit_req_body because r-per_dir_config is NULL. I'll spend
some
time on this tomorrow unless
On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
Broke more than proxy, without a rebuild all. Time for an MMN bump, it seems :)
I was wondering about that. =) What are the rules for a MMN bump?
-- justin
From: Justin Erenkrantz [EMAIL PROTECTED]
Sent: Wednesday, January 02, 2002 4:56 PM
On Wed, Jan 02, 2002 at 04:46:01PM -0600, William A. Rowe, Jr. wrote:
Broke more than proxy, without a rebuild all. Time for an MMN bump, it seems :)
I was wondering about that. =) What are the rules
1 - 100 of 162 matches
Mail list logo
