> On 2 Feb 2018, at 15:44, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote:
>> Am 02.02.2018 um 15:42 schrieb Yann Ylavic <ylavic....@gmail.com>:
>> On Fri, Feb 2, 2018 at 3:25 PM, Plüm, Rüdiger, Vodafone Group
>> <ruediger.pl...@vodafone.com> wrote:>
>>>> -----Ursprüngliche Nachricht----- Von: Jim Jagielski
>>>> [mailto:j...@jagunet.com] Gesendet: Freitag, 2. Februar 2018 15:15
>>>> An: httpd <dev@httpd.apache.org> 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.


Reply via email to