++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 <minf...@sharp.fm> wrote: > > On 09 Feb 2018, at 7:12 AM, William A Rowe Jr <wr...@rowe-clan.net > <mailto: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 >> <mailto: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 > — >
