Hello Eric,
so I can safely assume that when using "%{VARNAME}C" for .e.g. like
(below) it does the trick/causes serious pain to me?
# CustomLog with format nickname
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{mycookie-name}i\"" common
CustomLog logs/access_log common
Can I also assume the documents (current) are perfectly fine since
"CookieLog Directive" does not have to be specified anymore like
"CookieLog 'filename'", but the imply is active "automagically" and can
be used like described above?
So this essentially mean I have to go through the configs and look for
such \"%{mycookie-name}i\" statements, right?
A "yes, yes, yes" to all questions would cause me relief. Thanks in
advance! :D
Best regards
Mathias Hollstein
______________________
Mathias Hollstein
Referat BIT II 5 (Wiesbaden)
Telefon: +49 (0) 611 75 2549
Telefax: +49 (0) 611 72 4000
Email: mathias.hollst...@bva.bund.de
Email: mathias.hollst...@destatis.de
Internet: www.bundesverwaltungsamt.de
www.bit.bund.de
www.destatis.de
On 24.03.2014 12:14, Eric Covener wrote:
> The vulnerability is not related to the archaic CookieLog directive.
> It's in the impl of logformat %{cookie-name}C.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
> For additional commands, e-mail: docs-h...@httpd.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org
