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

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

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

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,

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

> 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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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-

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

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

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

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

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

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=1634520 Hmmm… it’s actually only solved the URL too long problem, the hostname too long

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

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

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

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

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

> 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

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

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

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:

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

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

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

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

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

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

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

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)

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)

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

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

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

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

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?

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