从JSP返回zip文件

我编写了一个简单的JSP，如果请求包含包含包含“gzip”的Accept编码头，则返回JavaScript文件的压缩版本，否则返回解压缩版本

<%@ page language="java"%>

<%
    boolean zipVersionRequired = false;
    try
    {
            String acceptEncodingHeader = request.getHeader("Accept-Encoding");

            if (acceptEncodingHeader != null && acceptEncodingHeader.indexOf("gzip") != -1)
            {
                    zipVersionRequired = true;
                    response.setHeader("Content-Encoding", "gzip");        
            }
            response.setHeader("Content-Type", "text/javascript");
    }
    catch (java.lang.Throwable t)
    {
    }
%>

<% if (zipVersionRequired == true) {
%>
    <jsp:forward page="/files/zipped/f1.js.gz"/>
<% } else {
%>
<jsp:forward page="/files/unzipped/f1.js"/>
<%
}
%>

值得注意的是，我将内容类型设置为“text/javascript”，但根据我的浏览器，响应头的值是“application/x-gzip”——不确定设置在哪里。内容编码响应标头设置为“gzip”。在Chrome开发者工具中，响应本身看起来像一堆奇怪的符号，所以我假设浏览器没有解压缩响应

我已经编写了一个servlet来完成同样的工作——它根据Accept Encoding请求头读取压缩文件或解压缩文件的内容，并将内容写回客户端。该servlet工作正常，但我想知道在JSP版本中我做错了什么

我正在使用Tomcat web服务器，但请不要建议将连接器上的compression=on设置作为解决方案，因为在这种情况下，这不是一个选项

谢谢

---

Paul

谢谢developerwk的评论

这太长了，无法作为回复添加到您的评论中，因此将其作为回复发布（并且有一个答案；请参见下文）

我很想知道为什么您（developerwk）认为jsp:include比jsp:forward更合适。如果我使用jsp:include，我会得到一个非法状态异常。我想我理解其中的原因——JSP servlet使用PrintWriter，当我使用JSP:include包含gz文件时，gz后缀是一个可识别的mime类型，并被识别为二进制类型，因此OutputStream被打开，导致了一个非法状态异常。那只是我的猜测

所以我使用forward，消除了所有的空白（我在生成的Java中检查了这一点），并得到了与originall post相同的问题-因此问题与jsp中的空白无关（无论如何，在使用jsp:forward时不是这样）

然后我找到了它不起作用的原因——这是响应中的内容类型标题。这是由Tomcat设置的，因为默认web.xml文件中的文件扩展名（gz）映射为mime类型（application/x-gzip）。当我将.gz文件重命名为.xxxxx时，响应中的内容类型头与我设置的内容类型头相匹配（text/javascript），浏览器（Chrome）成功解压响应并运行javascript。当然，我会在war的web.xml中添加mime类型映射，而不是在任何实际解决方案中使用.xxxxx扩展名

最后一件事——我希望jsp:include（其中包含的文件是.xxxxx文件）可以工作，只要jsp不包含空格——它就不工作。我没有收到任何响应内容，并且出现以下错误（在Chrome上）：

我还在仔细考虑那件事

---

Paul

在第一次使用前，请清除无意义的空白

Failed to load resource: net::ERR_CONTENT_DECODING_FAILED