2

我有一个愚蠢的问题，响应标头仅显示在 304 响应中。我使用的服务器是 Tomcat 7。java 过滤器包含以下代码：

HttpServletResponse httpResponse = (HttpServletResponse) response;

httpResponse.addHeader("Access-Control-Allow-Origin", "*");
httpResponse.addHeader("Access-Control-Allow-Credentials", "true");
httpResponse.addHeader("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT");
httpResponse.addHeader("Access-Control-Allow-Headers", "Content-Type, Accept");

if (debug) {
    httpResponse.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1
    httpResponse.setHeader("Pragma", "no-cache"); // HTTP 1.0
    httpResponse.setDateHeader("Expires", 0); // Proxies.
} else {
    httpResponse.setHeader("Cache-Control", "public");
    httpResponse.setDateHeader("Expires", System.currentTimeMillis() + 86400000L); // 1Day 
}

重要的是要注意，这个过滤器是链中最后一个触发的，它是 web.xml 中映射的第一个过滤器（如果它是最后一个也没有区别），上面的代码在之后运行

chain.doFilter(request, response);

使用 Chrome 的审核工具来评估标头我注意到在 200 上标头不在响应中。我通过按“F5”刷新页面，这会导致 304 并且可以看到标题。同样，我再次刷新并获得 200，其中标题不可见。反复刷新页面会在 304 和 200 响应之间交替，并且在每个 304 上都有标题，但在 200 上却没有。

过滤器映射到所有资源。

<filter-mapping>
    <filter-name>AllowRemoteAccessHeaderFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>HttpCachingFilter</filter-name>
    <url-pattern>*</url-pattern>
</filter-mapping>

此外，无论响应如何，过滤器都会在每次刷新时触发。

有人可以向我解释这里实际发生了什么吗？我确信我错过了一些小东西。我的目标是在那里有一个 200 响应的标题。

编辑：注意到这适用于加载的第一页，但不适用于该页面上加载的任何资源，例如。脚本、图像、CSS 包括。

编辑：还注意到，如果我从页面中删除所有小脚本，那么标题就会出现。这两个 scriptlet 每个都包含通过另一个过滤器在请求对象中设置的数据。注入已编译 javascript 的示例如下：

<script type="text/javascript"><%= request.getAttribute("compiled-scripts")%></script>

问题：我可能找到了问题的原因，但没有找到解决方案。当我将编译后的脚本包含到页面中时，传输编码从内容长度设置更改为：

Transfer-Encoding:chunked

传输编码被分块的那一刻，标头不会通过。这可能解释了为什么在 304 上响应标头通过，因为内容长度是已知的，因此已设置。而在 200 上，内容长度是未知的，并且传输编码是分块的。

但是，我的问题仍然存在。我想包含已编译的脚本而不是引用它们以减少延迟和其他原因。我已经读过，为了防止传输编码分块，您需要手动设置内容长度，方法是将响应读取为字节。我不知道如何确定过滤器中的响应长度。

当传输编码被分块时，是否可以通过响应标头？

4

2 回答 2

0

如果目标是获得 200 响应，您可以试试这个：

httpResponse.setStatus(HttpServletResponse.SC_OK)

但是 304 响应并不是一个糟糕的响应。

于 2013-11-04T13:03:52.030 回答
0

我最终找到了答案。感谢这篇文章中的提示：为什么我需要在 JSP 中修改缓冲区和自动刷新属性？

更具体地说，这

当缓冲区刷新一次时，重定向或转发将不起作用，因为对 HTTP 响应标头的所有更改都必须在第一次将缓冲区发送到客户端时发生。

响应标头是在导致问题的 chain.doFilter() 之后设置的。通过在调用 chain.doFilter() 之前设置标题，问题得到了排序。这意味着响应标头正在通过所有请求和响应代码。

我的理解是，当缓冲区已满时，如本例所示，它会被刷新。这会导致分块响应。但是，在刷新缓冲区时，未设置标头。浏览器接收到第一个块减去响应头，并且只检查第一个块上的头。因此，通过在刷新缓冲区之前设置响应标头，浏览器会收到带有第一个块的标头。

于 2013-11-07T06:43:22.920 回答