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 <[email protected]> wrote: > > On 07 Feb 2018, at 8:46 PM, William A Rowe Jr <[email protected]> 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 > — >
