> On 2 Feb 2018, at 15:44, Stefan Eissing <[email protected]> wrote: > > > >> Am 02.02.2018 um 15:42 schrieb Yann Ylavic <[email protected]>: >> >> On Fri, Feb 2, 2018 at 3:25 PM, Plüm, Rüdiger, Vodafone Group >> <[email protected]> wrote:> >>> >>>> -----Ursprüngliche Nachricht----- Von: Jim Jagielski >>>> [mailto:[email protected]] Gesendet: Freitag, 2. Februar 2018 15:15 >>>> An: httpd <[email protected]> Betreff: Re: New ServerUID >>>> directive >>>> >>>> Why? If it is designed to not change between restarts then there >>>> are much easier ways to be unique, which it kinda already is, >>>> considering the actual structs being used. >> >> I don't know what "easier ways" you are thinking about, the one >> proposed here is not that complicated IMO. >> In any case the method we are currently using in mod_proxy_lb *is* >> changing accross restarts, mainly because of the line number. >> What if you add/remove a line before the <VirtualHost>? >> At least for graceful restarts, I think it shall not change, SHMs >> should be reused. > > Is it a hash across the config record of a server what would give > the desired behaviour?
We have several internal modules which sort of need this. In each case we generate a sha256 and a UUID based on the FQDN or IP address and the (first) port number it listens on. And we then log this with ‘info’ during startup; thus allowing an admin to at some later point add a ServerUUID to the list of ServerName, ServerAdmin, etc. as he or she sees fit. As in practice - we found that in the few times when you need to change that UUID - you are in effect doing that as part of switching to a new origin server or something like that at protocol level with respect to things like locks, caches and other short-transactions/connection RESTy things surviving stuff. That said - having this in the core and being able to routinely seed this extra into things like cookies is goodness. We do that a lot now - and it helps with simplifying compliance a lot. Dw.
