severity 227997 important tags 227997 upstream tags 227997 pending stop quit
Fabio: > it seems to me that this option can be used only when mod_usertrack is > statically compiled into apache (and in our case it is not > since we make use of DSO). "Compiled in" is poor choice of wording in the documentation. The module has worked fine as a DSO for all versions of apache I've used. Also what would is the point in distributing a module built as a DSO (or even allowing it to be buit as a DSO) when it only works if compiled in statically? Fabio: > I am also dowgrading the bug since the apache still serves the pages > correctly and it does not die completly (only the child is killed but > respawned immediatly). The child dies, but no content is returned on that child request. If you have the module turned on for all pages (as I have) then your http server effectively becomes useless. For users whose setup depends on this module (as mine does) then the severity of the bug is effectively grave. I realise that there are a lot of users who don't use the module and are therefore not affected by the bug, the documentation for the BTS suggests to me that important is the correct severity for this type of bug. Thom: > Um, this sounds like > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24483 Yes, the workaround suggested works fine for me. I see this bug is now noted on the apache web server front page. For reference on the BTS you have to specifically add: CookieName Apache to your httpd.conf - under normal circumstances, this configuration directive is optional with that being the default value. Carl
