On 23.10.2013 16:48, Dr Stephen Henson wrote:
> Well the handling remains in ssl_init_ctx_protocol but now an SSL_CONF_CTX
> with
> appropriate flags is created in moddssl_ctx_init. That is done because a valid
> SSL_CONF_CTX is needed to call SSL_CONF_cmd_value_type in
> ssl_cmd_SSLOpenSSLConfCmd
On 23/10/2013 15:30, Kaspar Brand wrote:
> On 22.10.2013 22:04, Dr Stephen Henson wrote:
>> Only bit I'm not completely sure about is the use of the SSL_CONF_CTX
>> structure
>> in modssl_ctx_t. It's done that way to avoid having to keep creating and
>> destroying the SSL_CONF_CTX for each directi
On 22.10.2013 22:04, Dr Stephen Henson wrote:
> Only bit I'm not completely sure about is the use of the SSL_CONF_CTX
> structure
> in modssl_ctx_t. It's done that way to avoid having to keep creating and
> destroying the SSL_CONF_CTX for each directive but a quick test showed it was
> creating se
On 21.10.2013 06:09, Trevor Perrin wrote:
> I looked at your patch. Besides lack of passphrase-handling, it
> breaks compatibility with existing config files (which assume
> certs/keys are matched by type, not order).
I don't think that "random order of multiple SSLCertificateFile and
SSLCertific
Should I continue this way? Simply to propose patches?
On Sat, Oct 19, 2013 at 4:13 PM, Eric Covener wrote:
> Currently, when the body is consumed by a handler, a side effect is
> reading footers that might be present and copying them to
> r->headers_in.
>
> This presents a series of problems.
>
On Wed, Oct 23, 2013 at 1:27 AM, William A. Rowe Jr. wrote:
>
> On Oct 22, 2013 5:14 PM, "Yann Ylavic" wrote:
> >
> >
> > Shouldn't this be safe from terminal controls, eg :
> > const char *name = process->short_name;
> > if (!name ||
> > !*name ||
> > ap_has_cntrl(name)) {
> > na
