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 <wr...@rowe-clan.net> 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" <j...@jagunet.com> 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 —