On 09/28/2015 06:00 AM, j...@apache.org wrote:
Author: jim
Date: Mon Sep 28 13:00:59 2015
New Revision: 1705681
URL: http://svn.apache.org/viewvc?rev=1705681&view=rev
Log:
Sync
[...]
Modified:
httpd/httpd/branches/2.4.17-protocols-http2/modules/ssl/ssl_engine_kernel.c
URL:
http://svn.apache.or
On 09/16/2015 12:20 AM, jaillet...@apache.org wrote:
> Author: jailletc36
> Date: Tue Sep 15 22:20:45 2015
> New Revision: 1703305
>
> URL: http://svn.apache.org/r1703305
> Log:
> Remove code related to 'AuthDigestEnableQueryStringHack'
>
> This has been undocumented for about 3 years now (see
On 10/01/2015 06:59 PM, Graham Leggett wrote:
> On 01 Oct 2015, at 5:43 PM, yla...@apache.org wrote:
>
>> URL: http://svn.apache.org/viewvc?rev=1706275&view=rev
>> Log:
>> mod_ssl: follow up to r1705823.
>> We still need to flush in the middle of a SSL/TLS handshake.
>
> Can you confirm why the
I am still unclear on why this flushing is even necessary... :/
> On Sep 30, 2015, at 2:30 PM, Ruediger Pluem wrote:
>
>
>
> On 09/29/2015 11:42 AM, yla...@apache.org wrote:
>> Author: ylavic
>> Date: Tue Sep 29 09:42:56 2015
>> New Revision: 1705823
>>
>> URL: http://svn.apache.org/viewvc?r
On 01 Oct 2015, at 5:43 PM, yla...@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1706275&view=rev
> Log:
> mod_ssl: follow up to r1705823.
> We still need to flush in the middle of a SSL/TLS handshake.
Can you confirm why the flushing is necessary?
In theory mod_ssl should be switchi
> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 1. Oktober 2015 16:47
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1705823 -
> /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
>
> On Thu, Oct 1, 2015 at 3:54 PM, Plüm, Rüdiger,
On Thu, Oct 1, 2015 at 3:54 PM, Plüm, Rüdiger, Vodafone Group
wrote:
>>
>> Looks like as neither ssl23_client_hello nor ssl23_write_bytes cause
>> BIO_flush to be called.
>
> Dumped the wrong memory section for a HEAP bucket. The contents of the heap
> bucket is actually (now a different session)
On 01 Oct 2015, at 4:31 PM, Nick Kew wrote:
>> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>
> One further thought there that might be easier to work,
> or a staging post on the way to your goal:
>
>
>X-USER = $_
> # (or whatever backref syntax you prefer).
>
The reas
Am 01.10.2015 um 16:29 schrieb Plüm, Rüdiger, Vodafone Group:
-Ursprüngliche Nachricht-
Von: Reindl Harald [mailto:h.rei...@thelounge.net]
Gesendet: Donnerstag, 1. Oktober 2015 15:18
An: dev@httpd.apache.org
Betreff: Re: SSLUseStapling: ssl handshake fails until httpd restart
Am 0
On Thu, 1 Oct 2015 15:25:38 +0200
Rainer Jung wrote:
> Am 01.10.2015 um 15:03 schrieb Jim Jagielski:
> > Doesn't mod_lua do this for you?
>
> But would it be the right tool to use whenever you want to apply a
> s/.../.../?
Some might say so (as some might say mod_perl or mod_rewrite).
>
> -Ursprüngliche Nachricht-
> Von: Reindl Harald [mailto:h.rei...@thelounge.net]
> Gesendet: Donnerstag, 1. Oktober 2015 15:18
> An: dev@httpd.apache.org
> Betreff: Re: SSLUseStapling: ssl handshake fails until httpd restart
>
>
>
> Am 01.10.2015 um 15:08 schrieb Reindl Harald:
> > Am
> -Ursprüngliche Nachricht-
> Von: Ruediger Pluem [mailto:rpl...@apache.org]
> Gesendet: Mittwoch, 30. September 2015 22:02
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1705823 -
> /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
>
> On 09/30/2015 08:30 PM, Ruediger Pluem wrote:
Am 01.10.2015 um 15:03 schrieb Jim Jagielski:
Doesn't mod_lua do this for you?
But would it be the right tool to use whenever you want to apply a
s/.../.../? I think the entry bar for mod_lua is higher than to get used
with s/.../.../ syntax in the expression parser - though the docs for
exp
Am 01.10.2015 um 15:08 schrieb Reindl Harald:
Am 01.10.2015 um 14:53 schrieb Plüm, Rüdiger, Vodafone Group:
not really, i had the error message just now again in FF, the difference
was that now a "try again" loaded the page but with
"SSLStaplingReturnResponderErrors" i would expect it invisibl
Am 01.10.2015 um 14:53 schrieb Plüm, Rüdiger, Vodafone Group:
-Ursprüngliche Nachricht-
Von: Reindl Harald [mailto:h.rei...@thelounge.net]
The default for SSLStaplingReturnResponderErrors is relatively odd.
Not sure why it has always defaulted to "on" (r829619), but setting it
to off sh
Doesn't mod_lua do this for you?
> On Oct 1, 2015, at 8:51 AM, Rainer Jung wrote:
>
> Am 01.10.2015 um 14:32 schrieb Nick Kew:
>> On Thu, 2015-10-01 at 12:26 +0200, Rainer Jung wrote:
>>> Since it gets more common to use the expression parser for string
>>> operations and not only for boolean ch
On Thu, 2015-10-01 at 13:32 +0100, Nick Kew wrote:
> > Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
> But I expect the line of least resistance would be to use
> plain regexp rather than expr.
Come to think of it, using regexp that looks a lot like:
${REMOTE_USER} =~ s/([^@]*)
> -Ursprüngliche Nachricht-
> Von: Reindl Harald [mailto:h.rei...@thelounge.net]
> Gesendet: Donnerstag, 1. Oktober 2015 13:38
> An: dev@httpd.apache.org
> Betreff: Re: SSLUseStapling: ssl handshake fails until httpd restart
>
>
>
> Am 30.09.2015 um 08:42 schrieb Kaspar Brand:
> > On 2
Am 01.10.2015 um 14:32 schrieb Nick Kew:
On Thu, 2015-10-01 at 12:26 +0200, Rainer Jung wrote:
Since it gets more common to use the expression parser for string
operations and not only for boolean checks, I think it would be useful
(and powerful) to support
s/PATTERN/REPLACEMENT/FLAGS
and allo
Am 01.10.2015 um 14:33 schrieb Eric Covener:
On Thu, Oct 1, 2015 at 6:26 AM, Rainer Jung wrote:
Since it gets more common to use the expression parser for string operations
and not only for boolean checks, I think it would be useful (and powerful)
to support
s/PATTERN/REPLACEMENT/FLAGS
and al
> -Ursprüngliche Nachricht-
> Von: Rainer Jung
> Gesendet: Donnerstag, 1. Oktober 2015 13:56
> An: dev@httpd.apache.org
> Betreff: Re: Expression Parser: search and replace with
> s/PATTERN/REPLACEMENT/FLAGS
>
>
> The example might be artificial and mod_header might support doing this
On Thu, Oct 1, 2015 at 6:26 AM, Rainer Jung wrote:
> Since it gets more common to use the expression parser for string operations
> and not only for boolean checks, I think it would be useful (and powerful)
> to support
>
> s/PATTERN/REPLACEMENT/FLAGS
>
> and allow back references in REPLACEMENT.
On Thu, 2015-10-01 at 12:26 +0200, Rainer Jung wrote:
> Since it gets more common to use the expression parser for string
> operations and not only for boolean checks, I think it would be useful
> (and powerful) to support
>
> s/PATTERN/REPLACEMENT/FLAGS
>
> and allow back references in REPLACE
On Thu, Oct 01, 2015 at 01:55:40PM +0200, Rainer Jung wrote:
> Something different. Example:
>
> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>
> ...
>
> The example might be artificial and mod_header might support doing
> this in another way, but IMHO it would be a nice general f
Am 01.10.2015 um 12:31 schrieb Graham Leggett:
On 01 Oct 2015, at 12:26 PM, Rainer Jung wrote:
Since it gets more common to use the expression parser for string operations
and not only for boolean checks, I think it would be useful (and powerful) to
support
s/PATTERN/REPLACEMENT/FLAGS
and
Am 30.09.2015 um 08:42 schrieb Kaspar Brand:
On 29.09.2015 18:24, Reindl Harald wrote:
i just restarted the servers and disabled stapling since all our
servcies where unreachable (before i write the second mail 5 different
hosts with several sites where affected)
in fact the error caching doe
On 01 Oct 2015, at 12:26 PM, Rainer Jung wrote:
> Since it gets more common to use the expression parser for string operations
> and not only for boolean checks, I think it would be useful (and powerful) to
> support
>
> s/PATTERN/REPLACEMENT/FLAGS
>
> and allow back references in REPLACEMENT
Since it gets more common to use the expression parser for string
operations and not only for boolean checks, I think it would be useful
(and powerful) to support
s/PATTERN/REPLACEMENT/FLAGS
and allow back references in REPLACEMENT. The operation would not try to
do the replacement in place b
28 matches
Mail list logo
