标题未设置似乎不与apache 2.4.10和php-fpm一起使用

我试图通过使用HTTP标头将php代码中的头文件传递回apache访问日志,如下所示:

Header note X-Userid userid Header unset X-Userid LogFormat "%h %l %{userid}n %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_with_php_userid CustomLog /var/log/apache2/access_log combined_with_php_userid 

使用mod_php ,用户标识按预期插入到日志中,而标题在发送到客户端之前未被设置。

当通过php-fpm运行时,使用下面一行,userid不会被插入到日志中,也不会在客户端HTTP头文件中取消设置。

 ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9001/var/html/$1 

最初我使用的是apache_note但这只适用于mod_php 。 我发现上面的解决scheme是将数据从PHP传递到Apache / php-fpm或nginx,但似乎并不适用于php-fpm。

有什么我需要启用或设置为Header unset php-fpm下工作?

虚拟主机configuration:

 <VirtualHost *:80> ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9001/web/ee2/sites/site.com/$1 ServerAdmin [email protected] DocumentRoot /web/ee2/sites/site.com ServerName site.dev Header note X-Userid userid Header unset X-Userid ErrorLog /var/log/apache2/site.dev-error_log LogFormat "%h %l %{userid}n %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_with_php_userid # also tried: # LogFormat "%h %l %{X-Userid}i %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_with_php_userid CustomLog /var/log/apache2/searchenginenews.com-access_log combined_with_php_userid <Directory /web/ee2/sites/site.com> AllowOverride All Require all granted </Directory> </VirtualHost> 

mod_proxy_fcgi将响应头添加到r-> err_headers_out,这意味着您至less应该使用:

 Header unset X-Userid always 

但没有理由不使用两者:

 Header always unset X-Userid Header unset X-Userid 

这是Apache API的一个不幸的部分,它stream入了mod_headers – 头文件可以存在于两个地方,这取决于它们是否意味着坚持不成功的响应。

从注释中的疑难解答中,我认为这是一个错误 – 从mod_proxy_fcgi返回的头文件似乎对mod_headers不可用, mod_headersmod_headers进程处理后与其结合使用。

现在,如果你需要这个行为来正确的工作,也许看一下nginx或者lighttpd,或者在Apache前面打一个HAProxy或者Varnish实例来以正确的方式进行日志logging和头文件操作?

这个问题很古老,但可能有助于寻找最终解决scheme的人:

作为包围Header unset指出未Header unset你应该在设置注意时设置条件“始终”:

 Header always note X-Userid userid Header always unset X-Userid 

使用%{userid}n作为variables的占位符(n来自“内部注释”,即mod_headers保存variables的值。

从文档 :

 Header [condition] note header value The optional condition argument determines which internal table of responses headers this directive will operate against. Despite the name, the default value of onsuccess does not limit an action to responses with a 2xx status code. Headers set under this condition are still used when, for example, a request is successfully proxied or generated by CGI, even when they have generated a failing status code.