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" <wr...@rowe-clan.net> 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" <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... >> >> > On Feb 8, 2018, at 10:51 AM, Graham Leggett <minf...@sharp.fm> wrote: >> > >> > On 07 Feb 2018, at 8:46 PM, William A Rowe Jr <wr...@rowe-clan.net> >> 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 >> > — >> > >> >>
