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

Reply via email to