304 Not Modified 上的 Retry-After 响应标头
我在这里发现了几个相关的问题
- Apache ignoring PHP headers while moving a 304< /一>
- <一href="https://stackoverflow.com/questions/5926452/304-response-does-not-set-custom-header-for-apache-with-mod-headers">304响应没有为apache设置自定义标头mod_headers
我也尝试做的是为我的同步服务实现拉取请求处理程序，该处理程序告诉数据库中的任何用户对象是否有任何更改。如果进行了更改，我会用对象名称及其 ID 列表进行响应。如果没有更改，我会发送 304 Not Modified 响应。
为了控制这些请求的频率，我想到了在所有响应中添加 Retry-After 标头。问题是 Apache 在发送 304 响应时剪切了所有标头。
根据RFC2616
如果条件 GET 使用了强缓存验证器（请参阅部分 13.3.3），响应不应包含其他实体标头。
但 Retry-After 不是实体标头。我错了还是遗漏了什么？
有什么解决方法吗？ 如果无法解决此问题（带有 Retry-After 标头的 304 响应），在这种情况下还有哪些其他选择？使用 204 No Content 代替 304 Not Modified 似乎合理吗？
I found a couple related questions here
- Apache ignoring PHP headers when sending a 304
- 304 response does not set custom header for apache with mod_headers
What I'm trying too do is to implement pull request handler fo my sync service that tells if there were any changes to any user's object in the database. If changes were made I respond with a list of object names and its IDs. If there is no changes I send a 304 Not Modified response.
To control frequency of these request I came with an idea to add a Retry-After header in all responses. The problem is that Apache cut all headers when 304 response being sent.
According to RFC2616
If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
But Retry-After is not an entity-header. Am I wrong or missing something?
Is there any workarounds?
If this can't be solved (304 response with Retry-After header) what are the other choices in this situation? Is it seems reasonable to use 204 No Content instead of 304 Not modified?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实证明，Apache 会针对 硬编码的标头名称集。对于 2.2.x 版本，它们是：
一种解决方法是重载该列表中的标头。例如，您可以滥用警告标头：
另请参阅：将详细的 REST 错误消息放在 HTTP 警告标头中，好/坏主意？
注意：尽管 Apache 已实现，RFC2616 似乎建议 重试后是合理的关于 304 响应：
It turns out that Apache filters 304 Not Modified responses against a hard-coded set of header names. For version 2.2.x they are:
One workaround is to overload a header in that list. For example, you could abuse the Warning header:
Also see: Putting detailed REST error message in HTTP Warning header, good/bad idea?
And note: despite Apache's implementation, RFC2616 seems to suggest that Retry-After is reasonable on 304 responses: