: -Original Message-
: From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
:
: --On Friday, August 13, 2004 10:02 AM -0700 Mathihalli, Madhusudan
: [EMAIL PROTECTED] wrote:
:
: I was wondering if there's any potential harm in increasing the
: LimitRequestFieldsize from it's
Hello,
I was wondering if there's any potential harm in increasing the
LimitRequestFieldsize from it's current value of 8k to something more
(like 32k).
Thanks
-Madhu
: -Original Message-
: From: Bill Stoddard [mailto:[EMAIL PROTECTED]
[SNIP]
:
: Here's some comparative numbers to chew on.
:
: One client and one server on 100Mbps network (cheapy
: 100Base-T switch);
: 50 simulated users hitting 7 URLs 100 times with flood
: (35,000
[Forwarding on behalf of Tair-Shian Chou who has problems getting his
mail through to [EMAIL PROTECTED] list]
-Madhu
-Original Message-
From: Tair-Shian Chou [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 3:10 PM
To: '[EMAIL PROTECTED]'
Subject: FW: Bug in AuthLDAPURL?
Hi
: -Original Message-
: From: Jeff Trawick [mailto:[EMAIL PROTECTED]
: Sent: Wednesday, June 30, 2004 5:50 AM
: To: [EMAIL PROTECTED]
: Subject: Re: CGI scripts and mod_cgid/mod_cgi
:
: Mathihalli, Madhusudan wrote:
: Hello,
:
: Upon doing a apachectl stop, shouldn't the CGI
Hello,
Upon doing a apachectl stop, shouldn't the CGI processes (forked by
mod_cgid or mod_cgi) also exit ?
-Madhu
: -Original Message-
: From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED]
[SNIP]
: Upon doing a apachectl stop, shouldn't the CGI processes
: (forked by
: mod_cgid or mod_cgi) also exit ?
:
: It depends, if they call setsid() and so on - there's no
: particular reason they should.
: -Original Message-
: From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
[SNIP]
:
: For the 'Ordinarily' case - it doesn't do it today. It can be easily
: done by having a kill (0, SIGTERM) just before
: mod_cgid/apache exits
: - but I don't know if it's portable.
:
: Wouldn't a
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 13, 2004 2:02 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: httpd-2.0 STATUS
For precedent there have already been two binary
backwards-incompatible changes made on the 2.0 branch of such
exposed but
I'm forwarding on behalf of my collegue (as his mails are not reaching
the list)
-Madhu
-Original Message-
From: CHOU,TAIR-SHIAN (HP-Cupertino,ex1)
[mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 7:04 PM
To: Mathihalli, Madhusudan
Subject: FW: util_ldap [Bug 29217] - Remove
Another mail..
-Madhu
-Original Message-
From: CHOU,TAIR-SHIAN (HP-Cupertino,ex1)
[mailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 7:05 PM
To: Mathihalli, Madhusudan
Subject: FW: util_ldap [Bug 29217] - Remove references to
calloc() and free()
-Original Message-
From
I have a patch that achieves the purpose - but it's more of a hack. I'm
looking for suggestions to clean it up.
Here's the current logic :
- user invokes apachectl updatecrl which sends a SIGUSR2 signal to the
parent process
- parent passes a UPDATE_CHAR down the POD to the child processes
- The
-Original Message-
From: Joshua Slive [mailto:[EMAIL PROTECTED]
[SNIP]
On Tue, 25 May 2004, Mathihalli, Madhusudan wrote:
I have a patch that achieves the purpose - but it's more of a hack.
I'm looking for suggestions to clean it up.
Here's the current logic :
- user invokes
-Original Message-
From: Joshua Slive [mailto:[EMAIL PROTECTED]
On Tue, 25 May 2004, Mathihalli, Madhusudan wrote:
AIUI, the 'graceful' restart forces the child processes join all the
threads and re-start. (Pl. let me know if this is incorrect).
The requirement is to update the crl
-Original Message-
From: Marc Stern [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 11:35 PM
To: [EMAIL PROTECTED]
Subject: Re: SSL_CLIENT_S_DN and proxy
From what I understand - and it seems confirmed by the test I
made - the header is modified (created) before Apache
Hi Marc,
If you're using httpd-2.1, did you already try something like
below ?
-Madhu
Index: mod_headers.c
===
RCS file: /home/cvs/httpd-2.0/modules/metadata/mod_headers.c,v
retrieving revision 1.59
diff -u -r1.59
Hi,
I just realized that Joe had already developed something similar
in httpd-2.1. The only difference was in the function names - I changed
his patch a little (to match httpd-2.0), and here it is..
-Madhu
Index: mod_headers.c
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 3:08 AM
Looks fine, though it doesn't handle errors in apr_atoi64
itself so it would be good to surround the calls with a single
errno = 0 / ... /
if (errno) return -1; check too.
It seems
-Original Message-
From: Hotmail [mailto:[EMAIL PROTECTED]
[SNIP]
I have the code for the OCSP check, but I'd like to check the
integration with everybody, as I will give the code back to
you - if you're interesting in it :-)
Great !
[SNIP]
Is somebody interesting in testing that
-Original Message-
From: Geoff Thorpe [mailto:[EMAIL PROTECTED]
[SNIP]
Just one :-) I hadn't been particularly clear about something
so wires may
have got crossed, there is a second patch lurking around and
it's purpose
is overlapped with the one you posted. The patch you sent
Hello,
mod_ssl dumps core when you specify a low cache size (Ex. 1)
OR in a manner similar to Bug 27751. In both the cases, the problem
arises because of a incorrect/incomplete assumption about the size of
the session data in the cache. The session when stored in the cache can
be a
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
apr_off_t is the right type to use since these are file offsets.
parse_byterange should probably check for integer overflow when
sizeof(apr_off_t) != sizeof(apr_int64_t), but if you have a 2gb file
and a 32-bit
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
What if the user really sent a
large value for a small file ? Instead of erroring out -
thanks to the
overflow mechanism, we'll probably end up serving a sane result -
Should we leave it that way ?
Oh, good point,
Hello,
On my HP-UX 11i box (64-bit os), if I build a 32-bit app (default), the
apr_off_t is a 4-byte entity and apr_int64_t is a 8-byte entity. I'm sure more than
one person has experienced something similar.
This is the part that I don't understand : In http_protocol.c:
Any comments ?
Here's another perspective : Why should a CGI process block the delivery of all those
signals that are not of interest to httpd ?
-Madhu
From: Mathihalli, Madhusudan
Sent: Tue 4/13/2004 9:15 AM
To: [EMAIL PROTECTED]
Subject: RE: mod_cgi
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 13, 2004 4:55 AM
To: [EMAIL PROTECTED]
Subject: Re: mod_cgi and apr_setup_signal_thread
Mathihalli, Madhusudan wrote:
I'm using the worker MPM for both mod_cgi and mod_cgid.
I don't see any httpd 2.0/apr 0.9 code which manipulates
SIGALRM. Can you
I'm using the worker MPM for both mod_cgi and mod_cgid.
I haven't tried prefork MPM - but I have a vague guess that the problem will not show
up in the prefork case.
-Madhu
From: Jeff Trawick [mailto:[EMAIL PROTECTED]
Sent: Mon 4/12/2004 4:23 AM
To: [EMAIL
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
[SNIP]
Apparently I'm not the only one suffering from the pool
cleanup abortion
at the shutdown:
http://issues.apache.org/bugzilla/show_bug.cgi?id=23238
Should Apache2 ignore signals during the pool cleanup operations
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
On Mon, Mar 29, 2004 at 11:58:46AM -0800, Mathihalli, Madhusudan wrote:
Sounds good - but you still need to delete the last_e.
This is what I asked before - why? The apr_brigade_destroy(b) call
deletes the EOC bucket
Sounds good - but you still need to delete the last_e.
-Madhu
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Monday, March 29, 2004 11:47 AM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] followup with EOC bucket type
On Fri, Mar 26, 2004 at 12:01:30PM -0800, Mathihalli
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
Nice! So this is the fix for #26562? Don't forget to update
the comment
before you commit, and it looks like this is a new flag since OpenSSL
0.9.6h so should use a compatibility ifdef:
#ifndef
Hello,
Should we just ignore the rest of the processing in core_output_filter after
deleting the EOC bucket ?
-Madhu
Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.270
diff -u
Now that we're discussing about shmcb, I had another question - I see the following in
shmcb.c
608 /* Work on the basis that you need 10 bytes index for each session
609 * (approx 150 bytes), which is to divide temp by 160 - and then
610 * make sure we err on having too
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
A question for you: why did you want to delete the EOC bucket in
core_output_filter? That code looks wrong too, since last_e is left
pointing at the deleted EOC bucket.
Well.. I thought the EOC is not specific to SSL
-Original Message-
From: Geoff Thorpe [mailto:[EMAIL PROTECTED]
[SNIP]
It's been a long time since I last looked at shmcb in any
detail, and it's possible that there were still bugs waiting
to turn up eventually just as it's also possible that some
of the porting to apache2 might have
Hello,
Apart from flagging OpenSSL to NOT lookup the internal cache for session-id's,
we should ALSO tell OpenSSL to NOT store the sessions ! This fixes my problem where
the httpd process size keeps increasing when SSLVerifyClient is enabled along with
SSLSessionCache.
-Madhu
Index:
AM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH ?] RE: SEGV in allocator_free
On Fri, Mar 19, 2004 at 06:51:41PM -0800, Mathihalli, Madhusudan wrote:
Do we need to do the following ? I tried it - the test continued to a
certain extent, only to fail again after some time (with the same
stack trace
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
I think the correct fix is to stop trying to send the shutdown from the
cleanup, which didn't actually work anyway. Can you test something
like:
It works (atleast I don't see any SEGV's). The question still remains, but
Hello,
Ever noticed the following set of messages in the error_log - they can really
fill up the log file pretty quickly! I can't really get much useful information (and I
don't even know what 'internal error' means ?)
---
[Wed Mar 24 13:55:46
Please apply the patch posted by Joe to ssl_engine_io.c. The problem should go away !
-Madhu
-Original Message-
From: Juanma Barranquero [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 5:51 AM
To: William A. Rowe, Jr.; [EMAIL PROTECTED]
Subject: Re: 2.0.49 rolled
On Thu, 18 Mar
-Original Message-
From: Geoff Thorpe [mailto:[EMAIL PROTECTED]
[SNIP]
---
[Wed Mar 24 13:55:46 2004] [error] shmcb_insert_encoded_session
internal error [Wed Mar 24 13:55:46 2004] [error] can't store a
session!
[Wed Mar 24 13:55:46 2004]
I guess it's just to give a good out-of-the-box experience !
(Oh look - apache understands my language pretty nicely - that's neat :) )
-Madhu
-Original Message-
From: Joshua Slive [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 9:33 AM
To: [EMAIL PROTECTED]
Subject: Re:
Hi,
I am trying to test a SSL Proxy server using sslswamp, and I'm running into
the following segmentation fault !
There appears to be some missing error checks in the APR library - here's the
backtrace:
(Apache 2.0.48 - and I haven't tried 2.0.49)
(gdb) bt
#0 0xc1ba2190:0 in
Well - there might as-well be a bug in httpd (I don't deny that)
But shouldn't APR protect itself against NULL pointers in allocator_free ?
-Madhu
-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
Sent: Friday, March 19, 2004 10:26 AM
To: Mathihalli, Madhusudan
Cc
, March 19, 2004 10:41 AM
To: Mathihalli, Madhusudan
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: SEGV in allocator_free
On Fri, 2004-03-19 at 19:08, Mathihalli, Madhusudan wrote:
Hi,
I am trying to test a SSL Proxy server using sslswamp,
and I'm running into the following
Somehow the message just went to Sander !
-Madhu
-Original Message-
From: Mathihalli, Madhusudan
Sent: Friday, March 19, 2004 11:01 AM
To: 'Sander Striker'
Subject: RE: SEGV in allocator_free
-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]
[SNIP
-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]
[SNIP]
allocator = 0x0, that's bad. You didn't do a full httpd rebuild, so
there is no way of telling what pool this is. Can you do a full
rebuild (with pool debugging enabled)? Is this vanilla httpd-2.0.48?
Pretty much
in allocator_free
At 01:30 PM 3/19/2004, Mathihalli, Madhusudan wrote:
-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]
[SNIP]
allocator = 0x0, that's bad. You didn't do a full httpd rebuild, so
there is no way of telling what pool this is. Can you do a full
rebuild
-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
At 01:30 PM 3/19/2004, Mathihalli, Madhusudan wrote:
-Original Message-
From: Sander Striker [mailto:[EMAIL PROTECTED]
[SNIP]
allocator = 0x0, that's bad. You didn't do a full httpd rebuild, so
-keepalive == AP_CONN_KEEPALIVE))) {
-Original Message-
From: Mathihalli, Madhusudan
Sent: Friday, March 19, 2004 5:48 PM
To: [EMAIL PROTECTED]
Subject: RE: SEGV in allocator_free
-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
At 01:30 PM 3/19/2004, Mathihalli
Hi,
If the -c option is given a arbitrarily huge value, ab dumps core.
(Try: ab -c 2147483647 http://foo.com/)
Here's a patch that limits the concurrency to MAX_CONCURRENCY (= 2). The actual
value of MAX_CONCURRENCY can be raised/lowered if you think the value is not
appropriate.
-Original Message-
From: Jeff Trawick [mailto:[EMAIL PROTECTED]
[SNIP]
Mathihalli, Madhusudan wrote:
Hi,
If the -c option is given a arbitrarily huge value,
ab dumps core.
(Try: ab -c 2147483647 http://foo.com/)
why does it dump core? malloc says sure I can give you 2GB
: Wednesday, March 17, 2004 9:57
AMTo: Mathihalli, Madhusudan;
[EMAIL PROTECTED]Subject: ab and users (was:[PATCH] ab.c: check
for invalid value forconcurrency)
Just a quick surveyon how robust ab should be.
Ithink that ab should not seg fault on any user parameters,
Icould spent some time
-Original Message-
From: Jeff Trawick [mailto:[EMAIL PROTECTED]
[SNIP]
heap allocation failed... I just wanted to know ;)
okay, so your max of 2 sounds reasonable (plenty generous)
to me... with
63K or so max ephemeral ports, you're not going to go far
unless connections
are
Oh man !! I don't know how I missed it
!
Thanks
-Madhu
-Original
Message-From: Jean-Jacques Clar
[mailto:[EMAIL PROTECTED]Sent: Wednesday, March 17, 2004 3:11
PMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject:
Re: cvs commit: httpd-2.0/support ab.c
The added call to
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
On Mon, Mar 08, 2004 at 11:59:44AM -0800, Mathihalli, Madhusudan wrote:
I've been using the sslswamp tool (which btw is great) to stress
apache - and once in a while, I keep getting a 'abortive close
Yep - I was actually in a dual-mind to propose it as a backport (since it's based on
the new mod_ssl.h).
I'll just remove the proposal for now (and let the fix come in as part of Bill Rowe's
proposal to backport entire mod_ssl 2.1 to mod_ssl 2.0)
Thanks,
-Madhu
-Original Message-
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
On Mon, Mar 08, 2004 at 11:59:44AM -0800, Mathihalli, Madhusudan wrote:
I've been using the sslswamp tool (which btw is great) to stress
apache - and once in a while, I keep getting a 'abortive close
Hi,
I've been using the sslswamp tool (which btw is great) to stress apache - and
once in a while, I keep getting a 'abortive close' with the following message in the
error_log. Any ideas why this is happening ?
(on hpux running apache 2.0.48 with worker mpm + openssl 0.9.7c)
[Mon Mar
-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
[SNIP]
--On Friday, March 5, 2004 12:20 AM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
But I have a better proposal - let us simply move back the
entire mod_ssl 2.1
back to 2.0. Only binary compat issues
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]
[SNIP]
I'm not familiar with mod_ssl internals, but is there any
reason we can't
move subprocess_env population to something early like
post-read-request?
as a per-connection thingy, HTTPS ought to be know before
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
What I'm proposing is something as simple as below, which lets you do
RewriteCond %{SSL:HTTPS} =on without needing +StdEnvVars...
are we on the same page?
I'd suggest having %{ENV:HTTPS}, %{ENV:SSL_CIPHER_...} - to
Here's a slightly modified version of Joe's patch to
- not segfault if rewrite_ssl_var_lookup is not available (mod_ssl not loaded)
- use SSL environment variables as %{ENV:HTTPS} or %{ENV:SSL_PROTOCOL}
I tested the patch with the following rules, and it appeared to work without causing
any
-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
[SNIP]
--On Wednesday, March 3, 2004 3:04 PM -0800 Mathihalli, Madhusudan
[EMAIL PROTECTED] wrote:
+/* support for ssl_var_lookup() */
+APR_DECLARE_OPTIONAL_FN(char *, ssl_var_lookup
-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
[SNIP]
--On Wednesday, March 3, 2004 4:24 PM -0800 Mathihalli, Madhusudan
[EMAIL PROTECTED] wrote:
I thought it'll be a little too much :) What if I don't compile with
mod_ssl - I'll have a whole bunch
-Original Message-
From: André Malo [mailto:[EMAIL PROTECTED]
[SNIP]
* Joe Orton [EMAIL PROTECTED] wrote:
On Mon, Mar 01, 2004 at 10:37:46AM -0800, Mathihalli,
Madhusudan wrote:
Hi,
Question: Can we use the environment variables setup by mod_ssl
in the RewriteCond
Hi,
Question: Can we use the environment variables setup by mod_ssl in the
RewriteCond directive ?
I believe there's some inconsistency there - the SSL environment variables are setup
in the r-subprocess_env during the hook_fixup phase, where as the RewriteCond
evaluates/expands the
Message-
From: Mathihalli, Madhusudan
Sent: Monday, March 01, 2004 10:38 AM
To: [EMAIL PROTECTED]
Subject: RewriteCond and SSL environment variables
Hi,
Question: Can we use the environment variables setup by
mod_ssl in the RewriteCond directive ?
I believe there's some inconsistency
Since I didn't receive any negative comments, I'll check it in.
-Madhu
-Original Message-
From: Mathihalli, Madhusudan
Sent: Thursday, February 26, 2004 11:58 AM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH-Modified-2] SSL not sending close alert message
Sorry - the earlier mail
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
ap_flush_conn can just use a single brigade with two buckets, no extra
variables needed there,
Hmmn.. will that not introduce a mem leak ?
also needs s/APU_DECLARE/AP_DECLARE in
eoc_bucket.c, and perhaps the
-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
[SNIP]
--On Thursday, February 26, 2004 10:17 AM -0800 Mathihalli,
Madhusudan
[EMAIL PROTECTED] wrote:
ap_flush_conn can just use a single brigade with two
buckets, no extra
variables needed there,
Hmmn
Sorry - the earlier mail was a result of my mis-understanding Joe's comment. Here's
the correct patch.
Thanks
-Madhu
Index: include/http_connection.h
===
RCS file: /home/cvs/httpd-2.0/include/http_connection.h,v
retrieving
-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
[SNIP]
+
AP_CORE_DECLARE(void) ap_flush_conn(conn_rec *c)
{
apr_bucket_brigade *bb;
apr_bucket *b;
+
+ap_end_connection(c);
I wouldn't split this out into two functions that both create
a brigade
-Original Message-
From: Greg Stein [mailto:[EMAIL PROTECTED]
[SNIP]
On Wed, Feb 25, 2004 at 09:16:04AM -0800, Justin Erenkrantz wrote:
--On Tuesday, February 24, 2004 4:49 PM -0800 Mathihalli,
Madhusudan wrote:
... brings up the question : do you still want the
finish_connection
More feedback incorporated !
-Madhu
Index: server/Makefile.in
===
RCS file: /home/cvs/httpd-2.0/server/Makefile.in,v
retrieving revision 1.91
diff -u -r1.91 Makefile.in
--- server/Makefile.in 2 Feb 2004 17:04:10 - 1.91
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
This is just back to what we had patches for already: doing an SSL
shutdown on any EOF bucket, right? Which is not right since you get an
EOS after each HTTP response, not at the end of the connection.
Hence the need
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
I wasn't sure whether or not this EOC bucket type should go in APR-util
or httpd. Filtering gurus, what say ye? That bit looks OK to me
otherwise with a licence header added to the new file.
Since the EOC bucket is
Argh.. stupid e-mail client..
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
I wasn't sure whether or not this EOC bucket type should go
in APR-util
or httpd. Filtering gurus, what say ye? That bit looks OK to me
otherwise with a licence header added to the new
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
[SNIP]
On Tue, 24 Feb 2004, Joe Orton wrote:
I wasn't sure whether or not this EOC bucket type should go
in APR-util
or httpd. Filtering gurus, what say ye? That bit looks OK to me
otherwise with a licence header
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
mod_ssl-side I'd just use the changes in the most recent patch I posted
with the CLOSE bucket test replaced with the EOC bucket test in the
output filter: in my testing you needed to turn off buffering in
Here's the new patch incorporating the feedback.
One thing that I'd like feedback : The eoc bucket is inserted by the
ap_end_connection() function(in server/connection.c) - and deleted by SSL in
ssl_engine_io.c. I don't feel comfortable with it.
Is that okay ? If not, what is a good place
Hi,
I started working on Justin's idea of creating a EOC bucket - to do a SSL
shutdown before the socket close(). But since the ap_flush_conn is called just before
closing the socket - I thought of doing the SSL shutdown during the flush itself. Let
me know what you think of this patch.
Oops.. A typo (in the second block - line 951,6...) during the cut-and-paste
operation. This mail has the corrected version.
-Madhu
-Original Message-
From: Mathihalli, Madhusudan
Sent: Monday, February 23, 2004 1:22 PM
To: '[EMAIL PROTECTED]'
Subject: [PATCH] SSL not sending close
Orton [mailto:[EMAIL PROTECTED]
Sent: Monday, February 23, 2004 2:07 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] SSL not sending close alert message
On Mon, Feb 23, 2004 at 01:22:05PM -0800, Mathihalli, Madhusudan wrote:
Hi,
I started working on Justin's idea of creating a EOC bucket
Oh.. forget it - it was some setting in my browser :(
Thanks
-Madhu
From: Mathihalli, Madhusudan
Sent: Mon 2/23/2004 3:16 PM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] SSL not sending close alert message
When I did a ssldump to analyze the default index.html
, APR_HOOK_MIDDLE);
/*ap_hook_handler (ssl_hook_Upgrade, NULL,NULL, APR_HOOK_MIDDLE); */
ssl_var_register();
-Original Message-
From: Mathihalli, Madhusudan
Sent: Friday, February 06, 2004 7:57 AM
To: [EMAIL PROTECTED]
Subject: RE: mod_ssl not sending Alert upon close
that the
socket got closed before SSL_shutdown was issued ?
-Madhu
-Original Message-
From: Mathihalli, Madhusudan
Sent: Wednesday, February 04, 2004 6:08 PM
To: [EMAIL PROTECTED]
Subject: RE: mod_ssl not sending Alert upon close ?
-Original Message-
From: Geoff Thorpe [mailto:[EMAIL
clients when comparing 1.3 and 2.0 behaviour?
On Thu, Feb 05, 2004 at 11:06:57AM -0800, Mathihalli, Madhusudan wrote:
Hi,
It's been a while since I played with the Apache code,
and it'll
be nice if somebody can help me here.
I put some debug statements in the ssl_engine_io.c
comments ?
-Madhu
-Original Message-
From: Mathihalli, Madhusudan
Sent: Thursday, February 05, 2004 1:31 PM
To: [EMAIL PROTECTED]
Subject: RE: mod_ssl not sending Alert upon close ?
I tried using all the three 'unclean', 'standard' and
'accurate' shutdown methods. I'm using MSIE 6.0
Hi,
I was playing with ssldump for the data transferred b/w browser and Apache
(2.0.48) - and realized that the Apache2 (+ mod_ssl) does not send the Alert message
to the client before closing the connection.
-Madhu
Here's the error_log output from Apache 1.3 (+ mod_ssl)
[04/Feb/2004
-Original Message-
From: Geoff Thorpe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 04, 2004 5:56 PM
To: [EMAIL PROTECTED]
Cc: Mathihalli, Madhusudan
Subject: Re: mod_ssl not sending Alert upon close ?
On February 4, 2004 04:39 pm, Mathihalli, Madhusudan wrote:
Hi,
I
Hi,
Just wanted to update y'all - I traced down the bottleneck to
mod_specweb99.c. The bottleneck is caused by the POST CAD_GET
transactions. If I eliminate the POST CAD_GET from the SPECweb99 requests,
I don't see any spiky activity - the CPU usage is steady at 100%.
More
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
[SNIP]
Two possibilities:
* the command/Fetch URI is stuck also, or
I don't think the client did any Fetch when apache stopped.
* something died holding the post lock, and it didn't get
automagically cleaned up.
I
-Original Message-
From: Sander Temme [mailto:[EMAIL PROTECTED]
[SNIP]
There's one more thing I noticed (might be specific to
HP-UX) : I saw more
errors with keepalive ON rather than when it was OFF.
I think you may be looking at a problem where server and client(s) are
messing with
Hi,
I'm trying to run the SPECweb99 against Apache (on a 1-way box).
I noticed that if I start one server process with a large number of threads
(1000), the server goes into a heavily sleep state (with around 80 % idle
time).
A first guess is that I'm using SysV semaphores, and a semlock
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
[SNIP]
On Wed, 3 Dec 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
instead of having the worker threads compete for the
incoming connections
(using ap_queue_pop .. and hence mutex_lock), assign the
connection
To: [EMAIL PROTECTED]
Subject: Re: Regarding worker MPM and queue_push/pop
On Dec 4, 2003, at 9:18 AM, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
[SNIP]
On Wed, 3 Dec 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1
-Original Message-
From: Bill Stoddard [mailto:[EMAIL PROTECTED]
[SNIP]
Are you using CGI scripts? (an aside... if so better be
using mod_cgid rather than mod_cgi with worker). Jeff may
have already pointed out to you a feature in the
AIX that would keep threads hanging around an
-Original Message-
From: Jeff Trawick [mailto:[EMAIL PROTECTED]
[SNIP]
While researching the AIX issue affecting mod_cgid, in which
kill() would not
report that a process was gone until up to 1 second after it
exited*, I
constructed a test program to expose the delay without using
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
[SNIP]
I'm glad you're making progress. But I'm wondering why
raising the mod_cgid
Listen backlog was so important. If 100 mod_cgid connections
wasn't enough at
some point, either the workload is spikey or the
1 - 100 of 272 matches
Mail list logo
