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

[Stefan Eissing]

> Am 15.02.2018 um 20:42 schrieb William A Rowe Jr :
> 
> On Thu, Feb 15, 2018 at 1:13 PM, Ruediger Pluem  wrote:
>> 
>> On 02/15/2018 07:26 PM, Jim Jagielski wrote:
>>> It seems like some serious overhead to force a function call
>>> for each and every access to a struct field, especially if
>> 
>> I don't see this in the proposal below. _sizeof() and / or _copy would IMHO 
>> only be needed in rare cases and probably
>> non critical pathes. They could be handy though.
>> I don't see any kind of _get / _set for each field below.
> 
> +1, those sorts of accessors are only interesting when doing
> something more than changing a member value. E.g. when
> a major part of the entire structure is rearranged triggered by
> specific member value changes.

+1 for palloc/copy/sizeof on major structs.

-1 for field accessors.

-Stefan

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

[William A Rowe Jr]

On Thu, Feb 15, 2018 at 1:13 PM, Ruediger Pluem  wrote:
>
> On 02/15/2018 07:26 PM, Jim Jagielski wrote:
>> It seems like some serious overhead to force a function call
>> for each and every access to a struct field, especially if
>
> I don't see this in the proposal below. _sizeof() and / or _copy would IMHO 
> only be needed in rare cases and probably
> non critical pathes. They could be handy though.
> I don't see any kind of _get / _set for each field below.

+1, those sorts of accessors are only interesting when doing
something more than changing a member value. E.g. when
a major part of the entire structure is rearranged triggered by
specific member value changes.

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

[William A Rowe Jr]

On Thu, Feb 15, 2018 at 12:26 PM, Jim Jagielski  wrote:
> It seems like some serious overhead to force a function call
> for each and every access to a struct field, especially if
> it's only so we can adjust those struct fields w/o a corresponding
> change in the ABI...

Why would you do that?

The only modules who would call these functions would be those making
a duplicate of the entire structure.

Why does this happen? mod_cluster rearranges shm slots, I'm guessing.
mod_ftp took a completely generic server_rec, duplicated it, then
changed the value of the document_root member, and seeded new
request_rec structures in response to ftp commands. There are many
examples of why a _create() accessor is a good thing for module
developers, but it's not impossible to imagine these modules having a
need to make _copy() of one of our structures.

However we solve, the function template could be macroized, e.g.

#define AP_DECLARE_STRUCT_ACCESSORS(stype) \
  AP_DECLARE(struct stype *) ap_##stype##_palloc(apr_pool_t *p); \
  AP_DECLARE(apr_size_t) ap_##stype##_sizeof(); \
  AP_DECLARE(void) ap_##stype##_copy(struct stype *new, struct stype *orig);

#define AP_IMPLEMENT_STRUCT_ACCESSORS(stype) \
  AP_DECLARE(struct stype *) ap_##stype##_palloc(apr_pool_t *p) \
  { return apr_pcalloc(p, sizeof(struct stype)); } \
  AP_DECLARE(apr_size_t) ap_##stype##_sizeof() \
  { return sizeof(new); } \
  AP_DECLARE(void) ap_##stype##_copy(struct stype *new, struct stype *orig) \
  { return memcpy(new, orig, sizeof(struct stype)); }

The apr_stype_create() call has a whole lot more decorative things to
do by default, and can't really be macroized, but should be split as
necessary into context-free default initialization (ap_stype_create)
and the current phase-specific core logic (e.g. most of
core_create_conn as implemented today.)

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

[Ruediger Pluem]

On 02/15/2018 07:26 PM, Jim Jagielski wrote:
> It seems like some serious overhead to force a function call
> for each and every access to a struct field, especially if

I don't see this in the proposal below. _sizeof() and / or _copy would IMHO 
only be needed in rare cases and probably
non critical pathes. They could be handy though.
I don't see any kind of _get / _set for each field below.

> it's only so we can adjust those struct fields w/o a corresponding
> change in the ABI...


Regards

Rüdiger

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

[Jim Jagielski]

It seems like some serious overhead to force a function call
for each and every access to a struct field, especially if
it's only so we can adjust those struct fields w/o a corresponding
change in the ABI...

> On Feb 15, 2018, at 10:03 AM, William A Rowe Jr  wrote:
> 
> I've long been in favor of every httpd struct having an exposed _create() 
> function. It hadn't occurred to me to expose either a _sizeof() or _copy() 
> accessor, but mod_ftp could use this (until Stefan introduced the idea of run 
> time server_rec merging.)
> 
> What is the preference? _sizeof() or _copy()?
> 
> 
> 
> On Feb 15, 2018 03:42, "Joe Orton"  > wrote:
> On Wed, Feb 07, 2018 at 06:52:28PM +0100, Yann Ylavic wrote:
> > 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.
> 
> It's not getting a veto from me, but as an FYI I know there is at least
> one module (mod_cluster) which breaks when proxy_shared_worker is
> extended, because it has some fixed dependency on
> sizeof(proxy_shared_worker), e.g. it's used in a memcpy or something.
> We saw a similar case with mod_wsgi and sizeof(request_rec) a while ago.
> 
> I think it's always reasonable to extend structs unless we document an
> explicit ABI guarantee around *not* doing that, so the third-party
> modules have to deal with this.
> 
> Regards, Joe

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

[William A Rowe Jr]

On Thu, Feb 15, 2018 at 12:06 PM, Graham Leggett  wrote:
> On 15 Feb 2018, at 5:03 PM, William A Rowe Jr  wrote:
>
>> I've long been in favor of every httpd struct having an exposed _create() 
>> function. It hadn't occurred to me to expose either a _sizeof() or _copy() 
>> accessor, but mod_ftp could use this (until Stefan introduced the idea of 
>> run time server_rec merging.)
>>
>> What is the preference? _sizeof() or _copy()?
>
> I’m guessing they’re both useful. The implementations could in theory be 
> macros?

How does a macro solve binary compatibility?

The point is to ensure that sizeof(struct given_rec) changes in a
previously compiled module, when the core httpd is upgraded and more
members added to struct given_rec, that the entire given_rec contents
are copied to their new buffer, without being aware of the contents or
purpose of those unanticipated new members.

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

[Graham Leggett]

On 15 Feb 2018, at 5:03 PM, William A Rowe Jr  wrote:

> I've long been in favor of every httpd struct having an exposed _create() 
> function. It hadn't occurred to me to expose either a _sizeof() or _copy() 
> accessor, but mod_ftp could use this (until Stefan introduced the idea of run 
> time server_rec merging.)
> 
> What is the preference? _sizeof() or _copy()?

I’m guessing they’re both useful. The implementations could in theory be macros?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[William A Rowe Jr]

I've long been in favor of every httpd struct having an exposed _create()
function. It hadn't occurred to me to expose either a _sizeof() or _copy()
accessor, but mod_ftp could use this (until Stefan introduced the idea of
run time server_rec merging.)

What is the preference? _sizeof() or _copy()?



On Feb 15, 2018 03:42, "Joe Orton"  wrote:

> On Wed, Feb 07, 2018 at 06:52:28PM +0100, Yann Ylavic wrote:
> > 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.
>
> It's not getting a veto from me, but as an FYI I know there is at least
> one module (mod_cluster) which breaks when proxy_shared_worker is
> extended, because it has some fixed dependency on
> sizeof(proxy_shared_worker), e.g. it's used in a memcpy or something.
> We saw a similar case with mod_wsgi and sizeof(request_rec) a while ago.
>
> I think it's always reasonable to extend structs unless we document an
> explicit ABI guarantee around *not* doing that, so the third-party
> modules have to deal with this.
>
> Regards, Joe
>

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

[Jim Jagielski]

Bumping MMN should do that, right?

> On Feb 15, 2018, at 4:41 AM, Joe Orton  wrote:
> 
> On Wed, Feb 07, 2018 at 06:52:28PM +0100, Yann Ylavic wrote:
>> 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.
> 
> It's not getting a veto from me, but as an FYI I know there is at least 
> one module (mod_cluster) which breaks when proxy_shared_worker is 
> extended, because it has some fixed dependency on 
> sizeof(proxy_shared_worker), e.g. it's used in a memcpy or something.  
> We saw a similar case with mod_wsgi and sizeof(request_rec) a while ago.
> 
> I think it's always reasonable to extend structs unless we document an 
> explicit ABI guarantee around *not* doing that, so the third-party 
> modules have to deal with this.
> 
> Regards, Joe

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

[Joe Orton]

On Wed, Feb 07, 2018 at 06:52:28PM +0100, Yann Ylavic wrote:
> 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.

It's not getting a veto from me, but as an FYI I know there is at least 
one module (mod_cluster) which breaks when proxy_shared_worker is 
extended, because it has some fixed dependency on 
sizeof(proxy_shared_worker), e.g. it's used in a memcpy or something.  
We saw a similar case with mod_wsgi and sizeof(request_rec) a while ago.

I think it's always reasonable to extend structs unless we document an 
explicit ABI guarantee around *not* doing that, so the third-party 
modules have to deal with this.

Regards, Joe

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

[William A Rowe Jr]

For the match of balancer://group/ I don't believe length adds any value.
The one and hopefully final strcmp to validate the hash elt election should
accomplish this. From that point it becomes simple sting concatenation.

The optimization is getting us to that elt.

On Feb 13, 2018 11:32 AM, "Yann Ylavic"  wrote:

> On Tue, Feb 13, 2018 at 3:19 PM, Graham Leggett  wrote:
> >
> > Another option for the name is to store a URL prefix length and a hash of
> > the prefix. If the hash of the prefix matches, we have a match. Would
> this
> > work, would it be too expensive to hash on every hit, would it be safe
> > enough?
>
> It could work for prefix equality (with a keyed hash function like
> siphash to avoid collision forgery), though hashing every URL
> (possibly multiple times, for each different configured length) might
> be more costly than the current strncmp.
>
> But I suppose that the main issue is for regex matchings ("ProxyPass
> ~" and ProxyPassMatch)...
>
>
> Regards,
> Yann.
>

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

[Graham Leggett]

On 14 Feb 2018, at 2:43 PM, Jim Jagielski  wrote:

> ++1!
> 
> BTW: I'm fine with removing the hostname field in trunk and just having/using 
> hostname_ex

Agreed. Will do that after the backport is done.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[Jim Jagielski]

++1!

BTW: I'm fine with removing the hostname field in trunk and just having/using 
hostname_ex

> On Feb 13, 2018, at 9:19 AM, Graham Leggett  wrote:
> 
> On 09 Feb 2018, at 7:12 AM, William A Rowe Jr  > wrote:
> 
>> [Why] would you compare 8192 byte strings as identifiers?
> 
> I just checked the code, and as I suspected the “name” field isn’t a name, or 
> an identifier, it’s actually a URL prefix.
> 
> When a balancer is found to match, the “balancer:foo” is removed, and 
> replaced by the name, with the rest of the URL postfixed to it.
> 
> As you can see - we’re currently arbitrarily limiting the length of the URL 
> prefix to 256 characters, because 640k is big enough for everybody.
> 
>> On Feb 8, 2018 2:39 PM, "Jim Jagielski" > > wrote:
>> Another, much more extensive and intrusive fix would be to create
>> each ind field dynamically and tuck away in the  proxy_worker_shared
>> struct the SHM field to be attached to which holds the actual dynamically
>> allocated string. Better on SHM usage (our current usage is sloppy regarding
>> SHM utilization due to the fixed char arrays, most of which aren't
>> full) but more complex in other ways.
>> 
>> Idea would be to use the actual name and generate a hash from
>> that, use the hash as the SHM filename, create the SHM using
>> that filename (hash) to dynamically allocate the host string
>> and then store in proxy_worker_shared the hash (filename) used.
>> Attach to that SHM as needed.
>> 
>> Cleanup would need some thought…
> 
> Another option for the name is to store a URL prefix length and a hash of the 
> prefix. If the hash of the prefix matches, we have a match. Would this work, 
> would it be too expensive to hash on every hit, would it be safe enough?
> 
> For the hostname, the field only has to be 256 characters long (because 
> RFC1035 says it must be) and that’s manageable. I have created a patch to do 
> this and it works for me.
> 
> Regards,
> Graham
> —
> 

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

[Yann Ylavic]

On Tue, Feb 13, 2018 at 3:19 PM, Graham Leggett  wrote:
>
> For the hostname, the field only has to be 256 characters long (because
> RFC1035 says it must be) and that’s manageable. I have created a patch to do
> this and it works for me.

Is it checked-in (can't see it)?


Thanks,
Yann.

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

[Yann Ylavic]

On Tue, Feb 13, 2018 at 3:19 PM, Graham Leggett  wrote:
>
> Another option for the name is to store a URL prefix length and a hash of
> the prefix. If the hash of the prefix matches, we have a match. Would this
> work, would it be too expensive to hash on every hit, would it be safe
> enough?

It could work for prefix equality (with a keyed hash function like
siphash to avoid collision forgery), though hashing every URL
(possibly multiple times, for each different configured length) might
be more costly than the current strncmp.

But I suppose that the main issue is for regex matchings ("ProxyPass
~" and ProxyPassMatch)...


Regards,
Yann.

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

[William A Rowe Jr]

On Tue, Feb 13, 2018 at 8:19 AM, Graham Leggett  wrote:
> On 09 Feb 2018, at 7:12 AM, William A Rowe Jr  wrote:
>
> [Why] would you compare 8192 byte strings as identifiers?
>
> I just checked the code, and as I suspected the “name” field isn’t a name,
> or an identifier, it’s actually a URL prefix.

Ah ha!

> When a balancer is found to match, the “balancer:foo” is removed, and
> replaced by the name, with the rest of the URL postfixed to it.
>
> As you can see - we’re currently arbitrarily limiting the length of the URL
> prefix to 256 characters, because 640k is big enough for everybody.

Got it. I had misunderstood, thanks for clarifying.

Must this replacement be stored in a fixed SHM buffer? Or can this
be stored in the member data in pconf, in its minimal buffer length?
We might lose display details from a prior graceful restart generation.
Guess I need to examine the dynamic reconfig feature set.


>> On Feb 8, 2018 2:39 PM, "Jim Jagielski"  wrote:
>>>
>>> Another, much more extensive and intrusive fix would be to create
>>> each ind field dynamically and tuck away in the  proxy_worker_shared
>>> struct the SHM field to be attached to which holds the actual dynamically
>>> allocated string. Better on SHM usage (our current usage is sloppy
>>> regarding
>>> SHM utilization due to the fixed char arrays, most of which aren't
>>> full) but more complex in other ways.
>>>
>>> Idea would be to use the actual name and generate a hash from
>>> that, use the hash as the SHM filename, create the SHM using
>>> that filename (hash) to dynamically allocate the host string
>>> and then store in proxy_worker_shared the hash (filename) used.
>>> Attach to that SHM as needed.
>>>
>>> Cleanup would need some thought…
>
> Another option for the name is to store a URL prefix length and a hash of
> the prefix. If the hash of the prefix matches, we have a match. Would this
> work, would it be too expensive to hash on every hit, would it be safe
> enough?

> For the hostname, the field only has to be 256 characters long (because
> RFC1035 says it must be) and that’s manageable. I have created a patch to do
> this and it works for me.

I'm ok with comparing the 256 characters of the URL, although
a hash could be a great optimization, hashing is already a key
asset of Maglev LB; https://research.google.com/pubs/pub44824.html

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

[Graham Leggett]

On 09 Feb 2018, at 7:12 AM, William A Rowe Jr  wrote:[Why] would you compare 8192 byte strings as identifiers?I just checked the code, and as I suspected the “name” field isn’t a name, or an identifier, it’s actually a URL prefix.When a balancer is found to match, the “balancer:foo” is removed, and replaced by the name, with the rest of the URL postfixed to it.As you can see - we’re currently arbitrarily limiting the length of the URL prefix to 256 characters, because 640k is big enough for everybody.On Feb 8, 2018 2:39 PM, "Jim Jagielski"  wrote:Another, much more extensive and intrusive fix would be to create
each ind field dynamically and tuck away in the  proxy_worker_shared
struct the SHM field to be attached to which holds the actual dynamically
allocated string. Better on SHM usage (our current usage is sloppy regarding
SHM utilization due to the fixed char arrays, most of which aren't
full) but more complex in other ways.

Idea would be to use the actual name and generate a hash from
that, use the hash as the SHM filename, create the SHM using
that filename (hash) to dynamically allocate the host string
and then store in proxy_worker_shared the hash (filename) used.
Attach to that SHM as needed.

Cleanup would need some thought…Another option for the name is to store a URL prefix length and a hash of the prefix. If the hash of the prefix matches, we have a match. Would this work, would it be too expensive to hash on every hit, would it be safe enough?For the hostname, the field only has to be 256 characters long (because RFC1035 says it must be) and that’s manageable. I have created a patch to do this and it works for me.Regards,Graham—

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

[William A Rowe Jr]

After such a harsh response, I aught to point out Jim is right.

WTF would you compare 8192 byte strings as identifiers? Once again Graham I
think you are out of your mind.

By digesting the whole scheme://host/uri down to a hash, we have a
manageable and comparable unit to evaluate. The idea of trashing 8k in shm
for an 'unallocated' and unnecessary storage unit is absurd.

On Feb 8, 2018 11:04 PM, "William A Rowe Jr"  wrote:

> Since you won't permit 2.6/3.0 to come into existence, we can presume this
> was just a strawman?
>
>
>
> On Feb 8, 2018 2:39 PM, "Jim Jagielski"  wrote:
>
>> Another, much more extensive and intrusive fix would be to create
>> each ind field dynamically and tuck away in the  proxy_worker_shared
>> struct the SHM field to be attached to which holds the actual dynamically
>> allocated string. Better on SHM usage (our current usage is sloppy
>> regarding
>> SHM utilization due to the fixed char arrays, most of which aren't
>> full) but more complex in other ways.
>>
>> Idea would be to use the actual name and generate a hash from
>> that, use the hash as the SHM filename, create the SHM using
>> that filename (hash) to dynamically allocate the host string
>> and then store in proxy_worker_shared the hash (filename) used.
>> Attach to that SHM as needed.
>>
>> Cleanup would need some thought...
>>
>> > On Feb 8, 2018, at 10:51 AM, Graham Leggett  wrote:
>> >
>> > On 07 Feb 2018, at 8:46 PM, William A Rowe Jr 
>> wrote:
>> >
>> >> In order to find the slot, we need to strcmp. 512 is arbitrary, does
>> this
>> >> become an 8192 byte identifier? Or do we insist people distill names to
>> >> fit into a schema, much like DNS or file names, as the *identifier*?
>> >
>> > Right now the identifier is the URL prefix, and that URL prefix is
>> imposed on our users externally - we can’t insist people do anything,
>> because that anything will be “use a different server”.
>> >
>> > If the value is a hostname, then it needs to conform to RFC1035 (255
>> chars + nul).
>> >
>> > If the value is an URL (such as the name of each balancer) then we need
>> to be at least 255 chars for the hostname in the URL, plus space for the
>> rest of the URL. We could dynamically do this by following LimitRequestLine
>> but that might be tricky, and we recommend people don’t fiddle with
>> LimitRequestLine anyway.
>> >
>> > My suggestion is we extend the struct with a name_ex (or name2) and a
>> hostname_ex that have 8192 and 256 respectively. This is backportable, and
>> won’t fail in any server with default LimitRequestLine.
>> >
>> > Regards,
>> > Graham
>> > —
>> >
>>
>>

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

[William A Rowe Jr]

Since you won't permit 2.6/3.0 to come into existence, we can presume this
was just a strawman?



On Feb 8, 2018 2:39 PM, "Jim Jagielski"  wrote:

> Another, much more extensive and intrusive fix would be to create
> each ind field dynamically and tuck away in the  proxy_worker_shared
> struct the SHM field to be attached to which holds the actual dynamically
> allocated string. Better on SHM usage (our current usage is sloppy
> regarding
> SHM utilization due to the fixed char arrays, most of which aren't
> full) but more complex in other ways.
>
> Idea would be to use the actual name and generate a hash from
> that, use the hash as the SHM filename, create the SHM using
> that filename (hash) to dynamically allocate the host string
> and then store in proxy_worker_shared the hash (filename) used.
> Attach to that SHM as needed.
>
> Cleanup would need some thought...
>
> > On Feb 8, 2018, at 10:51 AM, Graham Leggett  wrote:
> >
> > On 07 Feb 2018, at 8:46 PM, William A Rowe Jr 
> wrote:
> >
> >> In order to find the slot, we need to strcmp. 512 is arbitrary, does
> this
> >> become an 8192 byte identifier? Or do we insist people distill names to
> >> fit into a schema, much like DNS or file names, as the *identifier*?
> >
> > Right now the identifier is the URL prefix, and that URL prefix is
> imposed on our users externally - we can’t insist people do anything,
> because that anything will be “use a different server”.
> >
> > If the value is a hostname, then it needs to conform to RFC1035 (255
> chars + nul).
> >
> > If the value is an URL (such as the name of each balancer) then we need
> to be at least 255 chars for the hostname in the URL, plus space for the
> rest of the URL. We could dynamically do this by following LimitRequestLine
> but that might be tricky, and we recommend people don’t fiddle with
> LimitRequestLine anyway.
> >
> > My suggestion is we extend the struct with a name_ex (or name2) and a
> hostname_ex that have 8192 and 256 respectively. This is backportable, and
> won’t fail in any server with default LimitRequestLine.
> >
> > Regards,
> > Graham
> > —
> >
>
>

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

[Jim Jagielski]

Another, much more extensive and intrusive fix would be to create
each ind field dynamically and tuck away in the  proxy_worker_shared
struct the SHM field to be attached to which holds the actual dynamically
allocated string. Better on SHM usage (our current usage is sloppy regarding
SHM utilization due to the fixed char arrays, most of which aren't
full) but more complex in other ways.

Idea would be to use the actual name and generate a hash from
that, use the hash as the SHM filename, create the SHM using
that filename (hash) to dynamically allocate the host string
and then store in proxy_worker_shared the hash (filename) used.
Attach to that SHM as needed.

Cleanup would need some thought...

> On Feb 8, 2018, at 10:51 AM, Graham Leggett  wrote:
> 
> On 07 Feb 2018, at 8:46 PM, William A Rowe Jr  wrote:
> 
>> In order to find the slot, we need to strcmp. 512 is arbitrary, does this
>> become an 8192 byte identifier? Or do we insist people distill names to
>> fit into a schema, much like DNS or file names, as the *identifier*?
> 
> Right now the identifier is the URL prefix, and that URL prefix is imposed on 
> our users externally - we can’t insist people do anything, because that 
> anything will be “use a different server”.
> 
> If the value is a hostname, then it needs to conform to RFC1035 (255 chars + 
> nul).
> 
> If the value is an URL (such as the name of each balancer) then we need to be 
> at least 255 chars for the hostname in the URL, plus space for the rest of 
> the URL. We could dynamically do this by following LimitRequestLine but that 
> might be tricky, and we recommend people don’t fiddle with LimitRequestLine 
> anyway.
> 
> My suggestion is we extend the struct with a name_ex (or name2) and a 
> hostname_ex that have 8192 and 256 respectively. This is backportable, and 
> won’t fail in any server with default LimitRequestLine.
> 
> Regards,
> Graham
> —
> 

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

[Graham Leggett]

On 07 Feb 2018, at 8:46 PM, William A Rowe Jr  wrote:

> In order to find the slot, we need to strcmp. 512 is arbitrary, does this
> become an 8192 byte identifier? Or do we insist people distill names to
> fit into a schema, much like DNS or file names, as the *identifier*?

Right now the identifier is the URL prefix, and that URL prefix is imposed on 
our users externally - we can’t insist people do anything, because that 
anything will be “use a different server”.

If the value is a hostname, then it needs to conform to RFC1035 (255 chars + 
nul).

If the value is an URL (such as the name of each balancer) then we need to be 
at least 255 chars for the hostname in the URL, plus space for the rest of the 
URL. We could dynamically do this by following LimitRequestLine but that might 
be tricky, and we recommend people don’t fiddle with LimitRequestLine anyway.

My suggestion is we extend the struct with a name_ex (or name2) and a 
hostname_ex that have 8192 and 256 respectively. This is backportable, and 
won’t fail in any server with default LimitRequestLine.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[Yann Ylavic]

On Thu, Feb 8, 2018 at 10:34 AM, Ruediger Pluem  wrote:
>
> So I think neither truncating nor increasing the field size is backportable.

What could possibly be considered backportable is adding a new
"fullname" field (char[256]) at the end of proxy_worker_shared.
That would be 2.4.x only, while we can (and should) rearrange
proxy_worker_shared in trunk.

Regards,
Yann.

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

[Ruediger Pluem]

On 02/07/2018 07: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.
>>
>> Why double that?
> 
> Because the part of the URL that matters to the admin might be at the end, as 
> in Dirk’s example. If we’ve consumed the
> whole length on the hostname, we leave nothing for the URL itself.
> 
> Eg: https://very-very-long-hostname/foo/bar/baz/veryimportant1 and
> https://very-very-long-hostname/foo/bar/baz/veryimportant2
> 
> The burning question is - are these fields only used for debugging, and 
> therefore an approximation is fine, or are they
> used for something else where precision is required?

IMHO they are used by mod_proxy_hcheck to set a host header for the "check" 
request and for getting the IP of the
backend. So truncating does not seem to be an option unless fixed there. But 
even if we fix mod_proxy_hcheck, what makes
us sure that other 3rd party modules do not do the same?

There is a comment in mod_proxy.h of 2.4.x that says:

"The addition of member uds_path in 2.4.7 was an incompatible API change. "

Increasing the length of the fields in proxy_worker_shared would IMHO be 
incompatible as well since proxy_worker_shared
is in mod_proxy.h and hence part of the public API.

So I think neither truncating nor increasing the field size is backportable.


Regards

Rüdiger

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

[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 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 code, the struct proxy_worker_shared is used by the
>> ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in
>> proxy_util.c and therefore mod_proxy.so.
>> 
>> The only user of these two functions is mod_proxy_balancer - so this looks
>> safe as per your definition above.
>> 
>> We need to document whether the name, scheme and hostname fields in
>> proxy_worker_shared are intended for debugging purposes only (ie logging,
>> status, errors) and are therefore safe to truncate or whether they can be
>> used programmatically. I don’t see anything in mod_proxy_balancer that
>> references these fields.
>> 
>> IIRC, it's just for mod_status output. Nothing programmatic.
> 
> As an external representation - if mod_status is compiled against 2.4.29,
> will it crash with this backport?

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

[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. The pairing of
> httpd-2.4.30
> and the 2.4.30 mod_proxy_balancer are obviously in-sync.
>
>
> Digging through the code, the struct proxy_worker_shared is used by the
> ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in
> proxy_util.c and therefore mod_proxy.so.
>
> The only user of these two functions is mod_proxy_balancer - so this looks
> safe as per your definition above.
>
> We need to document whether the name, scheme and hostname fields in
> proxy_worker_shared are intended for debugging purposes only (ie logging,
> status, errors) and are therefore safe to truncate or whether they can be
> used programmatically. I don’t see anything in mod_proxy_balancer that
> references these fields.
>
> IIRC, it's just for mod_status output. Nothing programmatic.

As an external representation - if mod_status is compiled against 2.4.29,
will it crash with this backport?

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

[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
>> httpd-2.4.30
>> and the 2.4.30 mod_proxy_balancer are obviously in-sync.
> 
> Digging through the code, the struct proxy_worker_shared is used by the 
> ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in 
> proxy_util.c and therefore mod_proxy.so.
> 
> The only user of these two functions is mod_proxy_balancer - so this looks 
> safe as per your definition above.
> 
> We need to document whether the name, scheme and hostname fields in 
> proxy_worker_shared are intended for debugging purposes only (ie logging, 
> status, errors) and are therefore safe to truncate or whether they can be 
> used programmatically. I don’t see anything in mod_proxy_balancer that 
> references these fields.
> 

IIRC, it's just for mod_status output. Nothing programmatic.

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

[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.
>
> Why double that?
>
>
> Because the part of the URL that matters to the admin might be at the end,
> as in Dirk’s example. If we’ve consumed the whole length on the hostname, we
> leave nothing for the URL itself.
>
> Eg: https://very-very-long-hostname/foo/bar/baz/veryimportant1 and
> https://very-very-long-hostname/foo/bar/baz/veryimportant2
>
> The burning question is - are these fields only used for debugging, and
> therefore an approximation is fine, or are they used for something else
> where precision is required?

In order to find the slot, we need to strcmp. 512 is arbitrary, does this
become an 8192 byte identifier? Or do we insist people distill names to
fit into a schema, much like DNS or file names, as the *identifier*?

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

[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 matters to the admin might be at the end, as 
in Dirk’s example. If we’ve consumed the whole length on the hostname, we leave 
nothing for the URL itself.

Eg: https://very-very-long-hostname/foo/bar/baz/veryimportant1 and 
https://very-very-long-hostname/foo/bar/baz/veryimportant2

The burning question is - are these fields only used for debugging, and 
therefore an approximation is fine, or are they used for something else where 
precision is required?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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 code, the struct proxy_worker_shared is used by the 
ap_proxy_share_worker() and ap_proxy_find_workershm() both declared in 
proxy_util.c and therefore mod_proxy.so.

The only user of these two functions is mod_proxy_balancer - so this looks safe 
as per your definition above.

We need to document whether the name, scheme and hostname fields in 
proxy_worker_shared are intended for debugging purposes only (ie logging, 
status, errors) and are therefore safe to truncate or whether they can be used 
programmatically. I don’t see anything in mod_proxy_balancer that references 
these fields.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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.
>
>
> We’re using automated strings.
>
> The balancer name is a URL, the URL contains a hostname, the hostname length
> is governed by RFC1035. The hostname needs to be at least 256 (255 plus
> null), and therefore the URL needs to be at least 255 plus extra to cover
> the rest of the URL, which given we allow 8192 as an URL length elsewhere in
> the server, we should actually allow 8196 byte URLs, therefore 8192 byte
> names.
>
> From a diagnostics/debugging perspective, nothing is conveyed in a
> balancer name > 256 (realistically, >80, because it is a single token,
> but lets be consistent...) that the human can benefit from.
>
> In the automated configuration case, at some point, you devolve too
> much extra data down to a UUID that will be distinct, and be done with
> it, much as Dirk's example illustrates.
>
>
> In our automated configuration case we have a system with a name, and we
> want an Apache load balancer to expose an URL on that system with that name.
> The name of that system is not under our control.

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?

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

[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 contract. The pairing of
httpd-2.4.30
and the 2.4.30 mod_proxy_balancer are obviously in-sync.

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

[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

[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, the URL contains a hostname, the hostname length is 
governed by RFC1035. The hostname needs to be at least 256 (255 plus null), and 
therefore the URL needs to be at least 255 plus extra to cover the rest of the 
URL, which given we allow 8192 as an URL length elsewhere in the server, we 
should actually allow 8196 byte URLs, therefore 8192 byte names.

> From a diagnostics/debugging perspective, nothing is conveyed in a
> balancer name > 256 (realistically, >80, because it is a single token,
> but lets be consistent...) that the human can benefit from.
> 
> In the automated configuration case, at some point, you devolve too
> much extra data down to a UUID that will be distinct, and be done with
> it, much as Dirk's example illustrates.

In our automated configuration case we have a system with a name, and we want 
an Apache load balancer to expose an URL on that system with that name. The 
name of that system is not under our control.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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

[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 long as the change allows you to compile the backport and rebuild
> mod_proxy_balancer *alone*... without needing to rebuild all of the
> consumers, then your change is likely similarly safe for third party
> modules consuming our API.

Just mod_proxy_balancer and proxy_util...

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

[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 sort of ``service-zone-status-etc- address>’’ thing:
>
> casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201--32e6---0002
>
> so chopping of the end is a bit painful.
>
>
> Ideally the hostname should be 256 to match RFC1035, and the balancer name
> be larger still to accommodate (512? larger?), but recognise the pain of
> being able to backport it.

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.

>From a diagnostics/debugging perspective, nothing is conveyed in a
balancer name > 256 (realistically, >80, because it is a single token,
but lets be consistent...) that the human can benefit from.

In the automated configuration case, at some point, you devolve too
much extra data down to a UUID that will be distinct, and be done with
it, much as Dirk's example illustrates.

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 long as the change allows you to compile the backport and rebuild
mod_proxy_balancer *alone*... without needing to rebuild all of the
consumers, then your change is likely similarly safe for third party
modules consuming our API.

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

[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  (revision 1823472)
+++ modules/proxy/proxy_util.c  (working copy)
@@ -1727,7 +1727,8 @@
 return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
 }
 if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
-return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO()
+"Alert! worker hostname (%s) too long; truncated to: %s", 
uri.hostname, wshared->hostname);
 }
 wshared->flush_packets = flush_off;
 wshared->flush_wait = PROXY_FLUSH_WAIT;

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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:
> 
>   
> casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201--32e6---0002
> 
> so chopping of the end is a bit painful.

Ideally the hostname should be 256 to match RFC1035, and the balancer name be 
larger still to accommodate (512? larger?), but recognise the pain of being 
able to backport it.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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=1634520
> 
> Hmmm… it’s actually only solved the URL too long problem, the hostname too 
> long problem is still a fatal error:
> 
> ptr = apr_uri_unparse(p, , APR_URI_UNP_REVEALPASSWORD);
> if (PROXY_STRNCPY(wshared->name, ptr) != APR_SUCCESS) {
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO(02808)
> "Alert! worker name (%s) too long; truncated to: %s", ptr, 
> wshared->name
> );
> }
> if (PROXY_STRNCPY(wshared->scheme, uri.scheme) != APR_SUCCESS) {
> return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
> }
> if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
> return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
> }
> 
> Would this break if we did the same warning on hostname that’s done on the 
> full URL?

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


casemo-apiservice-backend-frankfurt-production-W0091-2a01-4f80-0201--32e6---0002

so chopping of the end is a bit painful.

Dw.


signature.asc
Description: Message signed with OpenPGP

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

[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=1634520 
>> 
> 
> Hmmm… it’s actually only solved the URL too long problem, the hostname too 
> long problem is still a fatal error:
> 
> ptr = apr_uri_unparse(p, , APR_URI_UNP_REVEALPASSWORD);
> if (PROXY_STRNCPY(wshared->name, ptr) != APR_SUCCESS) {
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO(02808)
> "Alert! worker name (%s) too long; truncated to: %s", ptr, 
> wshared->name
> );
> }
> if (PROXY_STRNCPY(wshared->scheme, uri.scheme) != APR_SUCCESS) {
> return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
> }
> if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
> return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
> }
> 
> Would this break if we did the same warning on hostname that’s done on the 
> full URL?
> 

+1 on removing that as fatal as well... I'll fix trunk and propose
for backport

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

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

Hmmm… it’s actually only solved the URL too long problem, the hostname too long 
problem is still a fatal error:

ptr = apr_uri_unparse(p, , APR_URI_UNP_REVEALPASSWORD);
if (PROXY_STRNCPY(wshared->name, ptr) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, ap_server_conf, APLOGNO(02808)
"Alert! worker name (%s) too long; truncated to: %s", ptr, wshared->name
);
}
if (PROXY_STRNCPY(wshared->scheme, uri.scheme) != APR_SUCCESS) {
return apr_psprintf(p, "worker scheme (%s) too long", uri.scheme);
}
if (PROXY_STRNCPY(wshared->hostname, uri.hostname) != APR_SUCCESS) {
return apr_psprintf(p, "worker hostname (%s) too long", uri.hostname);
}

Would this break if we did the same warning on hostname that’s done on the full 
URL?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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?
> 
> +1 (assuming the truncated value is unique)

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

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

http://svn.apache.org/viewvc?view=revision=1634520

I suspect my problem is that upstream (Ubuntu in this case) hasn’t picked up 
the changes.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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

[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?view=revision=1621367 it 
seems two changes are being made, one is to increase the sizes, the second is 
to accept a truncated value.

In theory, the “accept a truncated value” will work around the problem and be 
backport-able, is that true?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[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
> 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 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 really embarrassing - just sold the idea of an httpd based load 
>> balancer and it breaks direct out the box. What changes do I need to make to 
>> fix this? Any blockers?
>> 
>> Regards,
>> Graham
>> —
>> 
> 

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

[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 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 really embarrassing - just sold the idea of an httpd based load 
> balancer and it breaks direct out the box. What changes do I need to make to 
> fix this? Any blockers?
> 
> Regards,
> Graham
> —
> 

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

[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, DNS names are allowed to be 255 characters long.
>
> This is really embarrassing - just sold the idea of an httpd based load 
> balancer and it breaks direct out the box. What changes do I need to make to 
> fix this? Any blockers?
>
> Regards,
> Graham
> —
>

Hello Graham,

See https://bz.apache.org/bugzilla/show_bug.cgi?id=53218

I believe it is related to what you are talking about.

Cheers

Michal Karm Babacek

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7




signature.asc
Description: OpenPGP digital signature