> Am 10.04.2018 um 18:22 schrieb Joe Orton :
>
> I don't quite understand the new AP_MODULE_FLAG_ALWAYS_MERGE logic so
> I'm struggling to debug this, but I've had a couple of reports that
> configurations like:
>
> Listen 443 https
>
>
> ServerName www.example.com:443
> SSLCertificateF
Additional example of the brokeness. If you add
a SSL directive to the 2nd vhost in your example
- without the new MERGE feature:
> Am 10.04.2018 um 18:22 schrieb Joe Orton :
>
> Listen 443 https
>
>
> ServerName www.example.com:443
> SSLCertificateFile ...
>
>
>
> ServerName other.exa
urgs, sorry.
> Am 11.04.2018 um 11:16 schrieb yla...@apache.org:
>
> Author: ylavic
> Date: Wed Apr 11 09:16:56 2018
> New Revision: 1828883
>
> URL: http://svn.apache.org/viewvc?rev=1828883&view=rev
> Log:
> Revert r1828882's mergeinfo.
>
> Modified:
>httpd/httpd/branches/2.4.x/ (props c
It happens when trying to do the real merge before proposing ;)
On Wed, Apr 11, 2018 at 11:18 AM, ste...@eissing.org wrote:
> urgs, sorry.
>
>> Am 11.04.2018 um 11:16 schrieb yla...@apache.org:
>>
>> Author: ylavic
>> Date: Wed Apr 11 09:16:56 2018
>> New Revision: 1828883
>>
>> URL: http://svn.a
Feedback desired:
Checking my server logs, I regularly see clients using SNI with port
identifier,
as in: test.example.org:443
I am not sure what client that is, but we do not identify the vhost that is
(probably) intended. Then the request comes in, and there we have magic that
finds the corre
I guess this makes sense to avoid these kind of issues.
Regards
Rüdiger
> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Mittwoch, 11. April 2018 11:49
> An: dev@httpd.apache.org
> Betreff: SNI normalization?
>
> Feedback desired:
>
>
ISTR that the RFC about SNI forbids port numbers (I find it
unfortunate as a matter of fact, given that host names may contain
ports...).
Just to say that normalization may come with ports handling/relaxing
in several places, which I support!
On Wed, Apr 11, 2018 at 11:52 AM, Plüm, Rüdiger, Vodafo
On Mon, Apr 9, 2018 at 10:07 AM, Joe Orton wrote:
> On Thu, Apr 05, 2018 at 01:38:05PM +0200, Yann Ylavic wrote:
>> On Wed, Oct 11, 2017 at 4:48 PM, wrote:
>> > Author: jorton
>> > Date: Wed Oct 11 14:48:55 2017
>> > New Revision: 1811831
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1811831&v
Trying before proposing is always a good practice.
svn merge --dry-run
can help in this situation.
CJ
> Message du 11/04/18 11:25
> De : "Yann Ylavic"
> A : "httpd-dev"
> Copie à :
> Objet : Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/
>
> It happens when trying to do t
Good hint. Unfortunately, I also try to compile it as well, sometimes even run
tests... ;-)
> Am 11.04.2018 um 13:27 schrieb Marion et Christophe JAILLET
> :
>
> Trying before proposing is always a good practice.
>
>svn merge --dry-run
>
> can help in this situation.
>
>
> CJ
>
>
>
On Wed, Apr 11, 2018 at 1:27 PM, Marion et Christophe JAILLET
wrote:
> Trying before proposing is always a good practice.
Yes of course, was a joke, one even said to reviewing commits was good :)
>
>svn merge --dry-run
>
> can help in this situation.
Thanks! Never thought about it, will hel
Thanks for the responses, Stefan. I understand this a bit better now,
but it still seems very clearly like a regression.
On Wed, Apr 11, 2018 at 10:28:05AM +0200, Stefan Eissing wrote:
> Additional example of the brokeness. If you add
> a SSL directive to the 2nd vhost in your example
> - withou
> Am 11.04.2018 um 13:57 schrieb Joe Orton :
>
> Thanks for the responses, Stefan. I understand this a bit better now,
> but it still seems very clearly like a regression.
>
> On Wed, Apr 11, 2018 at 10:28:05AM +0200, Stefan Eissing wrote:
>> Additional example of the brokeness. If you add
>>
On Wed, Apr 11, 2018 at 2:11 PM, wrote:
> Author: jhriggs
> Date: Wed Apr 11 12:11:05 2018
> New Revision: 1828890
>
> URL: http://svn.apache.org/viewvc?rev=1828890&view=rev
> Log:
> mod_proxy_balancer: Add hot spare member type and corresponding flag (R). Hot
> spare members are
> used as drop-
> On 11 Apr 2018, at 08:28, Yann Ylavic wrote:
>
> On Wed, Apr 11, 2018 at 2:11 PM, wrote:
>> Author: jhriggs
>> Date: Wed Apr 11 12:11:05 2018
>> New Revision: 1828890
>>
>> URL: http://svn.apache.org/viewvc?rev=1828890&view=rev
>> Log:
>> mod_proxy_balancer: Add hot spare member type and cor
+1 on keeping the patch as is and not breaking it out as a "refactor" plus
a new feature.
We have seen WAY too many cases where a refactor has caused
issues. I'm not saying we shouldn't fix things, but major refactors
should, IMO, have a real-world need, and tangible improvement,
other than "I wan
On Wed, Apr 11, 2018 at 02:10:27PM +0200, Stefan Eissing wrote:
> What we fixed here is a bug, plain and simple. And if installations rely
> on a bug, they might break on an update. Seems unavoidable.
>
> Nowhere is this "a certificate is visible in other vhosts if it is configured
> in the
> firs
On 11 Apr 2018, at 07:11, jhri...@apache.org wrote:
>
> Author: jhriggs
> Date: Wed Apr 11 12:11:05 2018
> New Revision: 1828890
>
> URL: http://svn.apache.org/viewvc?rev=1828890&view=rev
> Log:
> mod_proxy_balancer: Add hot spare member type and corresponding flag (R). Hot
> spare members are
>
I did not advocate refactor for refactoring sake, was just a remark
about (possibly) staging "big" changes.
Here for instance ap_proxy_balancer_get_best_worker() refactor could
have been done on the existing code first, and then the code needed
for hot spare members be added to that common function
It's been awhile but I think hot standbys were added before we came
up with the idea of lb sets... And since people were using hot
standbys, we didn't want to force them to change their configs.
We can drop hot-standbys in trunk/2.5/2.6, but we'll need to keep
them in 2.4.
> On Apr 11, 2018, at 1
On Wed, Apr 11, 2018 at 4:56 PM, Joe Orton wrote:
> On Wed, Apr 11, 2018 at 02:10:27PM +0200, Stefan Eissing wrote:
>> What we fixed here is a bug, plain and simple. And if installations rely
>> on a bug, they might break on an update. Seems unavoidable.
>>
>> Nowhere is this "a certificate is vis
On Wed, Apr 11, 2018 at 5:49 PM, Yann Ylavic wrote:
> Maybe we need a global EXEC_ON_READ setting (before any vhost) to
> control/ignore AP_MODULE_FLAG_ALWAYS_MERGE?
Something like the attached possibly...
Index: include/http_config.h
==
On Wed, Apr 11, 2018 at 05:49:47PM +0200, Yann Ylavic wrote:
> I agree... to both Stefan's and your points of view here :p
YOU FENCE SITTER! :)
> We can hardly break existing configurations, even if they rely on a
> bug (our bug...).
> But another user (or the same!) may open a bug when her/his
>
Like this? Is this likely to break some other currently-working config?
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1828914)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -26
On Wed, Apr 11, 2018 at 6:41 PM, Joe Orton wrote:
> On Wed, Apr 11, 2018 at 05:49:47PM +0200, Yann Ylavic wrote:
>> I agree... to both Stefan's and your points of view here :p
>
> YOU FENCE SITTER! :)
:D
>
> I feel like it should be possible to restore the old behaviour simply by
> disabling the
On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton wrote:
> Like this? Is this likely to break some other currently-working config?
>
> Index: modules/ssl/ssl_engine_init.c
> ===
> --- modules/ssl/ssl_engine_init.c (revision 1828914)
>
On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic wrote:
> On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton wrote:
>> Like this? Is this likely to break some other currently-working config?
>>
>> Index: modules/ssl/ssl_engine_init.c
>> ===
>>
On Wed, Apr 11, 2018 at 01:37:22PM -0400, Eric Covener wrote:
> On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic wrote:
> > On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton wrote:
> >> Like this? Is this likely to break some other currently-working config?
> >>
> >> Index: modules/ssl/ssl_engine_init.c
>
Sorry William, didn't mean to disturb you. Just noticed some 2.5.1 and
2.5.1-dev strings appearing in commits.
Hope the project will roll another 2.5-dev soon. OpenSSL 1.1.1 is
nearing and a TLSv1.3 Apache server to go with that would be most
excellent!
Thanks! Bernard.
2018-04-10 17:35 GMT+02:0
> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
> @@ -459,6 +459,8 @@ typedef struct {
> char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authentication secret
> (e.g. AJP13) */
> char upgrade[
On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener wrote:
>> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
>> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
>> @@ -459,6 +459,8 @@ typedef struct {
>> char secret[PROXY_WORKER_MAX_SECRET_SIZE]; /* authenti
On Wed, Apr 11, 2018 at 7:54 PM, Joe Orton wrote:
> On Wed, Apr 11, 2018 at 01:37:22PM -0400, Eric Covener wrote:
>> On Wed, Apr 11, 2018 at 1:07 PM, Yann Ylavic wrote:
>> > On Wed, Apr 11, 2018 at 7:03 PM, Joe Orton wrote:
>> >> Like this? Is this likely to break some other currently-working c
On Wed, Apr 11, 2018 at 10:05 PM, Yann Ylavic wrote:
> On Wed, Apr 11, 2018 at 9:14 PM, Eric Covener wrote:
>>> --- httpd/httpd/trunk/modules/proxy/mod_proxy.h (original)
>>> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.h Wed Apr 11 19:11:52 2018
>>> @@ -459,6 +459,8 @@ typedef struct {
>>>
33 matches
Mail list logo