Thanks Jeff and Yann for your reviews. Fixed all items as suggested,
except for these ones:
The various calls to ssl_server_import_cert() in ssl_init_server_certs()
need different rc checking than before. (Now ssl_server_import_cert() can
return a fatal error instead of just a boolean.)
On Sat, Nov 23, 2013 at 7:24 AM, Kaspar Brand httpd-dev.2...@velox.chwrote:
Thanks Jeff and Yann for your reviews. Fixed all items as suggested,
except for these ones:
The various calls to ssl_server_import_cert() in ssl_init_server_certs()
need different rc checking than before. (Now
Date: Sat, 23 Nov 2013 13:24:53 +0100
From: httpd-dev.2...@velox.ch
To: dev@httpd.apache.org
Subject: Re: ssl_die() and pool cleanup
Thanks Jeff and Yann for your reviews. Fixed all items as suggested,
except for these ones:
The various calls
So, if the sanity check is skipped for the _default_ host, or there is a
better way to set the ServerName of the _default_ host, which I don't know
yet, then this wouldn't be affected.
I don't think any behavior should be based on _default_ vs. *.
Your scenario probably works the same with
Date: Sat, 23 Nov 2013 08:18:14 -0500
Subject: Re: ssl_die() and pool cleanup
From: cove...@gmail.com
To: dev@httpd.apache.org
So, if the sanity check is skipped for the _default_ host, or there is a
better way to set the ServerName of the _default_
On 23.11.2013 13:56, Jeff Trawick wrote:
Maybe I'm still missing something here, but it looks like we can still
survive some calls to ssl_die() this logic. (I guess it doesn't make sense
to have a configuration where that could happen, but it is confusing
looking at the code.) Look at the
On Sat, Nov 23, 2013 at 8:51 AM, Kaspar Brand httpd-dev.2...@velox.chwrote:
On 23.11.2013 13:56, Jeff Trawick wrote:
Maybe I'm still missing something here, but it looks like we can still
survive some calls to ssl_die() this logic. (I guess it doesn't make
sense
to have a configuration
On 23.11.2013 15:03, Jeff Trawick wrote:
IMO it adds some future-proofing and self explanation to return early if
(rv != APR_SUCCESS rv != APR_NOTFOUND) instead of just checking for
equality with APR_EGENERAL.
Done with r1544812. Note that I'm working towards nukeing
On Sat, Nov 23, 2013 at 10:02 AM, Kaspar Brand httpd-dev.2...@velox.chwrote:
On 23.11.2013 15:03, Jeff Trawick wrote:
IMO it adds some future-proofing and self explanation to return early if
(rv != APR_SUCCESS rv != APR_NOTFOUND) instead of just checking for
equality with APR_EGENERAL.
On Wed, Nov 20, 2013 at 5:19 AM, Kaspar Brand httpd-dev.2...@velox.chwrote:
On 18.11.2013 14:59, Jeff Trawick wrote:
Has anyone looked at making ssl_die() clean up pools on the way out
(presumably by calling some function besides exit())? It is rather easy
to
end up with a bunch of
Maybe sk_X509_NAME_pop_free(ca_list, X509_NAME_free) should be called too
before returning NULL in ssl_init_FindCAList() (so to avoid a leak in case
of failure).
Regards;
Yann.
On Fri, Nov 22, 2013 at 4:20 PM, Jeff Trawick traw...@gmail.com wrote:
On Wed, Nov 20, 2013 at 5:19 AM, Kaspar Brand
On Wed, Nov 20, 2013 at 5:19 AM, Kaspar Brand httpd-dev.2...@velox.chwrote:
On 18.11.2013 14:59, Jeff Trawick wrote:
Has anyone looked at making ssl_die() clean up pools on the way out
(presumably by calling some function besides exit())? It is rather easy
to
end up with a bunch of
Has anyone looked at making ssl_die() clean up pools on the way out
(presumably by calling some function besides exit())? It is rather easy to
end up with a bunch of stranded IPC objects while debugging your SSL config.
Commentary in ssl_die() suggests a great goal, but that's essentially
On Wed, 2002-12-18 at 21:55, Justin Erenkrantz wrote:
--On Wednesday, December 18, 2002 3:23 PM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
My proposed changes are:
- Create each top-level request pool as a free-standing pool,
rather than a subpool of the connection pool.
-
--On Thursday, December 19, 2002 9:28 AM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
If the connection is aborted after the metadata bucket is
pushed into the output filter chain, it would be the core
output filter's job to consume and destroy all remaining
buckets until it had processed the
On Thu, 2002-12-19 at 09:37, Justin Erenkrantz wrote:
--On Thursday, December 19, 2002 9:28 AM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
If the connection is aborted after the metadata bucket is
pushed into the output filter chain, it would be the core
output filter's job to consume and
--On Thursday, December 19, 2002 9:45 AM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
No, we definitely need to do that cleanup in core_output_filter,
because that's the only code that's guaranteed to still be runnable
by the time we detect the aborted connection. The handler may have
finished
On Thu, 2002-12-19 at 10:02, Justin Erenkrantz wrote:
--On Thursday, December 19, 2002 9:45 AM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
No, we definitely need to do that cleanup in core_output_filter,
because that's the only code that's guaranteed to still be runnable
by the time we
For 2.1, I'd like to change the way in which request pools
are destroyed. Currently, it's possible for a request to be
destroyed before the entire response is set.
My proposed changes are:
- Create each top-level request pool as a free-standing pool,
rather than a subpool of the connection
--On Wednesday, December 18, 2002 3:23 PM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
My proposed changes are:
- Create each top-level request pool as a free-standing pool,
rather than a subpool of the connection pool.
- After generating the response, don't destroy the request pool.
On Thu, Sep 20, 2001 at 07:02:58AM -0700, Ryan Bloom wrote:
On Wednesday 19 September 2001 02:21 pm, Greg Stein wrote:
...
They are not strictly LIFO. You can remove a cleanup and insert a new one
at any time. Let's say that the cleanup list looked like:
cleanups: A
and you add a
On Wed, Sep 19, 2001 at 12:16:24PM -0700, Ryan Bloom wrote:
On Wednesday 19 September 2001 11:37 am, William A. Rowe, Jr. wrote:
From: Greg Stein [EMAIL PROTECTED]
Sent: Wednesday, September 19, 2001 1:26 PM
...
The problem is cross-dependency between the cleanup actions. One can
22 matches
Mail list logo
