Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
No. > On Feb 7, 2018, at 2:08 PM, William A Rowe Jr wrote: > > On Wed, Feb 7, 2018 at 1:01 PM, Jim Jagielski wrote: >> >> On Feb 7, 2018, at 1:41 PM, Graham Leggett wrote: >> >> On 07 Feb 2018, at 8:34 PM, William A Rowe Jr wrote: >> >> So long as other mod_proxy_* compiled against 2.4.29

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread William A Rowe Jr
On Wed, Feb 7, 2018 at 1:01 PM, Jim Jagielski wrote: > > On Feb 7, 2018, at 1:41 PM, Graham Leggett wrote: > > On 07 Feb 2018, at 8:34 PM, William A Rowe Jr wrote: > > So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no > - it is doesn't seem we established an ABI contract

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
> On Feb 7, 2018, at 1:41 PM, Graham Leggett wrote: > > On 07 Feb 2018, at 8:34 PM, William A Rowe Jr > wrote: > >> So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no >> - it is doesn't seem we established an ABI contract. The pairing of >>

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread William A Rowe Jr
On Wed, Feb 7, 2018 at 12:45 PM, Graham Leggett wrote: > On 07 Feb 2018, at 8:36 PM, William A Rowe Jr wrote: > > But there is no argument for a name identifier >255 characters ... the cited > RFC > and the filesystem and so many others use this as the conventional > constraint > on an identifier

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 8:36 PM, William A Rowe Jr wrote: > But there is no argument for a name identifier >255 characters ... the cited > RFC > and the filesystem and so many others use this as the conventional constraint > on an identifier. > > Why double that? Because the part of the URL that ma

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 8:34 PM, William A Rowe Jr wrote: > So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no > - it is doesn't seem we established an ABI contract. The pairing of > httpd-2.4.30 > and the 2.4.30 mod_proxy_balancer are obviously in-sync. Digging through the co

Re: Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)

2018-02-07 Thread William A Rowe Jr
Is the sapi compiled against libtool etc. from httpd? Or is it using the configure logic shipped with the php package? In any case, asking httpd/apr to conform to the autoconf/libtool packaging of php, which was built using its own flavor of the toolchain seems inconsistent. It seems foolish to a

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread William A Rowe Jr
On Wed, Feb 7, 2018 at 11:39 AM, Graham Leggett wrote: > On 07 Feb 2018, at 7:04 PM, William A Rowe Jr wrote: > > These are fixed shm strings, IIRC? How is a balancer name >256 > characters usable in anything but automated strings, and the example > given by Dirk uses nowhere near 256 chars. > >

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread William A Rowe Jr
On Wed, Feb 7, 2018 at 11:33 AM, Jim Jagielski wrote: > So can I assume that a backport req to bump-up the field sizes to, at least, > what is in trunk, would not be vetoed? So long as other mod_proxy_* compiled against 2.4.29 do not crash, then no - it is doesn't seem we established an ABI cont

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Yann Ylavic
On Wed, Feb 7, 2018 at 6:33 PM, Jim Jagielski wrote: > So can I assume that a backport req to bump-up the field sizes to, at least, > what is in trunk, would not be vetoed? Not by me, +1.

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 7:04 PM, William A Rowe Jr wrote: > These are fixed shm strings, IIRC? How is a balancer name >256 > characters usable in anything but automated strings, and the example > given by Dirk uses nowhere near 256 chars. We’re using automated strings. The balancer name is a URL, th

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
So can I assume that a backport req to bump-up the field sizes to, at least, what is in trunk, would not be vetoed?

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
> On Feb 7, 2018, at 12:04 PM, William A Rowe Jr wrote: > > On Wed, Feb 7, 2018 at 9:07 AM, Jim Jagielski > wrote: >> Personally, I still think that updating these fields for 2.4.x >> makes sense and can be justified... but am in no mood >> for a battle *grin* > > As

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread William A Rowe Jr
On Wed, Feb 7, 2018 at 10:46 AM, Graham Leggett wrote: > On 07 Feb 2018, at 5:34 PM, Dirk-Willem van Gulik > wrote: > > Not sure how this broke on your end - but the cases where I had it break on > me in production where all cases where things were generated and dynamically > registered with some

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 5:33 PM, Jim Jagielski wrote: > +1 on removing that as fatal as well... I'll fix trunk and propose > for backport Something like this? Index: modules/proxy/proxy_util.c === --- modules/proxy/proxy_util.c (revisi

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 5:34 PM, Dirk-Willem van Gulik wrote: > Not sure how this broke on your end - but the cases where I had it break on > me in production where all cases where things were generated and dynamically > registered with some sort of ``service-zone-status-etc- address>’’ thing: > >

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Dirk-Willem van Gulik
> On 7 Feb 2018, at 16:24, Graham Leggett wrote: > > On 07 Feb 2018, at 5:18 PM, Graham Leggett wrote: > >> Looking back through the archives, looks like that backport was already >> accepted: >> >> http://svn.apache.org/viewvc?view=revision&revision=1634520 > > Hmmm… it’s actually only sol

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
> On Feb 7, 2018, at 10:24 AM, Graham Leggett wrote: > > On 07 Feb 2018, at 5:18 PM, Graham Leggett > wrote: > >> Looking back through the archives, looks like that backport was already >> accepted: >> >> http://svn.apache.org/viewvc?view=revision&revision=1634520

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 5:18 PM, Graham Leggett wrote: > Looking back through the archives, looks like that backport was already > accepted: > > http://svn.apache.org/viewvc?view=revision&revision=1634520 Hmmm… it’s actually only solved the URL too long problem, the hostname too long problem is st

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
PS: Want to propose it for back port, or should I? ;) > On Feb 7, 2018, at 10:16 AM, Jim Jagielski wrote: > > > >> On Feb 7, 2018, at 10:07 AM, Graham Leggett wrote: >> >> >> In theory, the “accept a truncated value” will work around the problem and >> be backport-able, is that true? > >

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 5:16 PM, Jim Jagielski wrote: >> In theory, the “accept a truncated value” will work around the problem and >> be backport-able, is that true? > > +1 (assuming the truncated value is unique) Looking back through the archives, looks like that backport was already accepted:

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
> On Feb 7, 2018, at 10:07 AM, Graham Leggett wrote: > > > In theory, the “accept a truncated value” will work around the problem and be > backport-able, is that true? +1 (assuming the truncated value is unique)

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
On 07 Feb 2018, at 5:04 PM, Jim Jagielski wrote: > I believe the issue are the various defines in > mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These > have been bumped up in trunk but have not been > backported to 2.4 due to perceived API/ABI issues. Looking at https://svn.apache.org/viewvc?vi

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
Personally, I still think that updating these fields for 2.4.x makes sense and can be justified... but am in no mood for a battle *grin* > On Feb 7, 2018, at 10:04 AM, Jim Jagielski wrote: > > I believe the issue are the various defines in > mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These > h

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Jim Jagielski
I believe the issue are the various defines in mod_proxy.h (eg: PROXY_WORKER_MAX_NAME_SIZE. These have been bumped up in trunk but have not been backported to 2.4 due to perceived API/ABI issues. > On Feb 7, 2018, at 9:52 AM, Graham Leggett wrote: > > Hi all, > > Just hit this error while tryin

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Michal Karm
On 02/07/2018 03:52 PM, Graham Leggett wrote: > Hi all, > > Just hit this error while trying to configure a load balancer: > > Feb 07 14:37:31 wap01 apache2[1804]: BalancerMember worker hostname > (xx-xx--x-x.xx--x.x-xxx.xxx.x.) too long > > According to RFC1035

BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

2018-02-07 Thread Graham Leggett
Hi all, Just hit this error while trying to configure a load balancer: Feb 07 14:37:31 wap01 apache2[1804]: BalancerMember worker hostname (xx-xx--x-x.xx--x.x-xxx.xxx.x.) too long According to RFC1035, DNS names are allowed to be 255 characters long. This is

Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)

2018-02-07 Thread Michael
a) It has been a hard climb to get httpd-2.4.29 to build using the latest apr and apr-util. Still researching what that is (might be expat related - embedded versus external, still searching). Anyway, working with apr-1.5.2 I was at least able to get httpd-2.4.29 to build so I could proceed to

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

2018-02-07 Thread Jim Jagielski
At this point, I no longer have a horse in this race... From a philosophical point of view, adding 10kgs of fluff to fix 1kg of error seems over-engineering to me, but that is just me. +1 for whatever you think is best... and thx for your work on this.

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

2018-02-07 Thread Yann Ylavic
On Wed, Feb 7, 2018 at 1:47 PM, Jim Jagielski wrote: > > Just curious if our current policy is to use a sledgehammer now > to fix what can be handled with a pair of tweezers. Btw, I also think this is a sledgehammer for the mod_proxy_lb case, while it wouldn't for s->server_id (IMHO).

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

2018-02-07 Thread Yann Ylavic
On Wed, Feb 7, 2018 at 1:47 PM, Jim Jagielski wrote: > Just for fun, what is the functional difference, if any, between this > very large patch, that adds lots of code, and this extremely simple > diff which, from what I can tell, handles the exact defined > "problem" with the original code??? Th

Re: Which server id for mod_proxy_lb? (was: New ServerUID directive)

2018-02-07 Thread Jim Jagielski
Just for fun, what is the functional difference, if any, between this very large patch, that adds lots of code, and this extremely simple diff which, from what I can tell, handles the exact defined "problem" with the original code??? Just curious if our current policy is to use a sledgehammer now

mod_ssl: support for forced renegotiation on timeout or bytes?

2018-02-07 Thread Pavel Janík
Hi, are there any plans to support openssl’s BIO_set_ssl_renegotiate_timeout and BIO_set_ssl_renegotiate_bytes in mod_ssl’s config? Please CC me on reply as I’m not subscribed to this list. Thank you. -- Pavel Janík