: -Original Message-
: From: Joshua Slive [mailto:[EMAIL PROTECTED]
: On Sun, 15 Aug 2004, Justin Erenkrantz wrote:
:
: > --On Sunday, August 15, 2004 7:30 PM -0700 "Mathihalli, Madhusudan"
: > <[EMAIL PROTECTED]> wrote:
: >
: >> I thought the 8K li
: -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
: >
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 reque
[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 Graha
: -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"
: -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.
:
: Would
: -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 shoul
Hello,
Upon doing a "apachectl stop", shouldn't the CGI processes (forked by
mod_cgid or mod_cgi) also exit ?
-Madhu
>-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
>"expo
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()
>
&g
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: F
>-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 incorrec
>-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
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
- Th
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
=
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 mod_header
>-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
>-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 s
>-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
>-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 sen
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 maxi
>-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,
>-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 apr
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:
parse_b
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_cg
iginal Message-
>From: Jeff Trawick [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_cg
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
Hello,
I recently came across a very simple cgi script that does a "ping". The script
hangs when mod_cgi is used but works correctly with mod_cgid !
Guess whatz the reason: the delivery of SIGALRM is disabled and 'ping' happens to use
SIGALRM !
Question: Can we enable SIGALRM without bre
>-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 oper
>-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_dest
2004 at 12:01:30PM -0800, Mathihalli, Madhusudan wrote:
>> Hello,
>> Should we just ignore the rest of the processing in
>> core_output_filter after deleting the EOC bucket ?
>
>Yes, I think so, but by not leaving last_e pointing at a deleted bucket
>it can be done
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 -r
>-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:
>
Just to make sure this is
>-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 SSL_SESS_CACHE_N
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: ss
>-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 ha
>-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
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]
>Are those who can reproduce this segfault using a reverse proxy to an
>SSL backend (i.e. SSLProxyEngine on)?
[SNIP]
Yes and No :)
Yes - I have the directive in the ssl.conf.
No - I'm not proxying to a SSL backend.
Ho
> -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:
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,
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 2004
>-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,
: Wednesday, March 24, 2004 7:49 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 e
|| (APR_BUCKET_IS_EOS(last_e)
&& c->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 Messa
>-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
;Subject: RE: SEGV 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 f
>-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
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-
>
CTED]
>Sent: Friday, 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 serve
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:
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 a
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: AddC
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 u
>-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 connection
PROTECTED]Sent: 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 survey on how robust ab should be.
I think that ab should not seg fault on any user parameters,
I c
>-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/)
>
>wh
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: 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
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-
>Fro
>-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
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 0
>-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 com
> -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
>-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 co
>-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
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 pro
>-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_...}
>-Original Message-
>From: Joe Orton [mailto:[EMAIL PROTECTED]
[SNIP]
>I think you've got it backwards: ssl_var_lookup always
>generates the SSL
>variables on the fly; it is used by the fixup handler to populate
>r->subprocess_env if +StdEnvVars, but works exactly the same regardless
>of
> -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 envi
ginal 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 inc
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 en
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
>-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 pro
>-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
&g
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 revision
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: 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:
>>
>> > ... bri
>-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
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 for
>-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
>bio_filte
>-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 h
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 adde
>-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
>-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
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
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
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 sen
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.
_HOOK_MIDDLE);
+ap_hook_log_transaction(ssl_hook_logger, NULL,NULL, 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
T
the lingering_close invoke the filter code for _CONNECTION_TYPE filters.
-Madhu
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Fri 2/6/2004 7:03 AM
To: [EMAIL PROTECTED]
Subject: Re: mod_ssl not sending Alert upon close ?
On Thu, Feb 05, 2004 at 02:03:29
OOPS ! The connection has already been terminated
Any 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
reproduce this?
>I presume you have the same SetEnvIf ssl-unclean-shutdown settings for
>broken 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 wit
number" => which means 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 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, Mathihal
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 1
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 comm
>-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 u
>-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
1 - 100 of 306 matches
Mail list logo
