Apache 在发送 304 时忽略 PHP 标头

发布于 2024-11-17 19:25:55 字数 285 浏览 5 评论 0原文

当我在 Apache + mod_php5 中设置自定义标头时,效果很好:

header('Foo: Bar');

但是当我尝试此操作同时还发送 304 Not Modified 响应时,该标头似乎已被 apache 删除(与 X-Powered 一起) -By 和其他标准标头)。

header('HTTP/1.1 304 No Content');
header('Foo: Bar');

有谁知道如何解决这个问题?

When I set a custom header in Apache + mod_php5, this works fine:

header('Foo: Bar');

But when I try this while also sending a 304 Not Modified response, the header appears to be removed by apache (along with X-Powered-By and other standard headers).

header('HTTP/1.1 304 No Content');
header('Foo: Bar');

Does anyone know how to solve this issue?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

私野 2024-11-24 19:25:55

这不是回答了问题吗?

如果条件 GET 使用强缓存验证器(请参阅第 13.3.3 节),则响应不应包含其他实体标头。否则(即,条件 GET 使用弱验证器),响应不得包含其他实体标头;这可以防止缓存的实体主体和更新的标头之间出现不一致。

来自 http://www.w3.org/Protocols/rfc2616/ rfc2616-sec10.html#sec10.3.5

Does this not answer the question?

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5

勿挽旧人 2024-11-24 19:25:55

从 Apache 2.4.23(据我所知,今天的最新版本)开始,当您发送 304“未修改”响应时,您将无法解决该问题,因为事实上,Apache 确实显式删除所有非白名单标头:

http://svn .apache.org/viewvc/httpd/httpd/tags/2.4.23/modules/http/http_filters.c?view=markup#l1331

所以,不管我们喜欢与否(因为当我发送 304 时,我也同意 Apache 从响应中删除我的 CORS 标头),Apache 似乎确实遵循了 RFC 建议,并且它确实正在处理所有可能出现的问题该列表之外作为实体标题。

一种解决方案是修补 Apache 源代码以扩展该列表,然后将您自己开发的软件包部署到您的服务器上,但这绝对不是没有一长串其本身的影响。另一方面,我听说 nginx 不会遇到这个问题。

我提供的内容将被标准浏览器中的 WebGL 运行时等消耗,因此,如果他们确实抱怨我的 304 响应中缺少 CORS,我将不得不将所有内容都转为 200 OK 并放弃节省带宽。

As of Apache 2.4.23 (the latest release as of today, as far as I know), you're not going to be able to get around that problem when you send a 304 "Not Modified" response because, indeed, Apache does explicitly remove all non-whitelisted headers:

http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.23/modules/http/http_filters.c?view=markup#l1331

So, whether we like it or not (because I'm on the same boat of having my CORS headers removed by Apache from the response when I send a 304), it does seem like Apache is following the RFC recommendation and it's indeed treating everything that falls outside of that list as entity headers.

One solution is to patch-up the Apache source to extend that list and turn to deploying your home-grown package to your server(s), but that's definitely not without a long list of implications of its own. On the flip side, I hear that nginx doesn't suffer from this problem.

The content that I'm delivering will be consumed, among others, by WebGL runtimes in standard browsers, so if they do complain about the lack of CORS in my 304 responses I'm going to have to turn everything to 200 OK and forego the bandwidth savings.

栀梦 2024-11-24 19:25:55

我用一个技巧来解决这个问题:
1. 将所有 header 放在 304 header 之前
2. 在发送 304 之前刷新这些标头

header('Foo: Bar');
flush();
header('HTTP/1.1 304 No Content');

Apache 在找到 304 之前不会删除任何标头。
我们在发送 304 之前强制通过flush()发送其他标头。
那阿帕奇不能伤害我。

I do a trick to solve this issue by :
1. put all header before 304 header
2. flush these header before send 304

header('Foo: Bar');
flush();
header('HTTP/1.1 304 No Content');

Apache will not remove any header until it found 304.
We force other header send out by flush() before send 304.
That apache can not hurt me.

甚是思念 2024-11-24 19:25:55

尝试:

header('Foo: bar', true, 304);

Try:

header('Foo: bar', true, 304);
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文