Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.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 >>> @@

Re: 2.4.3x regression w/SSL vhost configs

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

Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c

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

Re: svn commit: r1828926 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h modules/proxy/mod_proxy_http.c

> --- 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

Re: TLSv1.3

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

Re: 2.4.3x regression w/SSL vhost configs

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? > >> >

Re: 2.4.3x regression w/SSL vhost configs

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 >>

Re: 2.4.3x regression w/SSL vhost configs

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

Re: 2.4.3x regression w/SSL vhost configs

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

Re: 2.4.3x regression w/SSL vhost configs

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) @@

Re: 2.4.3x regression w/SSL vhost configs

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

Re: 2.4.3x regression w/SSL vhost configs

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

Re: 2.4.3x regression w/SSL vhost configs

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

Re: Future of hot standby in balancers [was Re: svn commit: r1828890 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ docs/manual/howto/ docs/manual/mod/ modules/proxy/ modules/proxy/balancers/]

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

Re: svn commit: r1828890 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ docs/manual/howto/ docs/manual/mod/ modules/proxy/ modules/proxy/balancers/

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

Future of hot standby in balancers [was Re: svn commit: r1828890 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ docs/manual/howto/ docs/manual/mod/ modules/proxy/ modules/proxy/balancers/]

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=rev > Log: > mod_proxy_balancer: Add hot spare member type and corresponding flag (R). Hot > spare members are >

Re: 2.4.3x regression w/SSL vhost configs

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 >

Re: svn commit: r1828890 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ docs/manual/howto/ docs/manual/mod/ modules/proxy/ modules/proxy/balancers/

+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

Re: svn commit: r1828890 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ docs/manual/howto/ docs/manual/mod/ modules/proxy/ modules/proxy/balancers/

> 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=rev >> Log: >>

Re: svn commit: r1828890 - in /httpd/httpd/trunk: ./ docs/log-message-tags/ docs/manual/howto/ docs/manual/mod/ modules/proxy/ modules/proxy/balancers/

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=rev > Log: > mod_proxy_balancer: Add hot spare member type and corresponding flag (R). Hot > spare members are

Re: 2.4.3x regression w/SSL vhost configs

> 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

Re: 2.4.3x regression w/SSL vhost configs

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 > -

Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/

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!

Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/

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

Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/

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

Re: svn commit: r1811831 - /httpd/httpd/trunk/server/util_script.c

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:

Re: SNI normalization?

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,

AW: SNI normalization?

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: > >

SNI normalization?

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

Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/

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 >>

Re: svn commit: r1828883 - /httpd/httpd/branches/2.4.x/

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=rev > Log: > Revert r1828882's mergeinfo. > > Modified: >httpd/httpd/branches/2.4.x/ (props

Re: 2.4.3x regression w/SSL vhost configs

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 ... > > > >

Re: 2.4.3x regression w/SSL vhost configs

> 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