Question

我在web.xml文件中使用以下xml将GzipFilter配置为我正在运行Jetty的Spring应用程序。我希望在使用Chrome中的开发人员工具进行检查时，资源大小会变小，我希望看到“编码”在响应头中具有值“gzip”。但是，这些都不可见。

然而，当我在IDE中使用调试工具进行检查时，我注意到应用了过滤器（我将断点指向GzipFilter），并且我注意到在使用开发人员工具进行检查时，etag-headers在响应中具有-gzip扩展名。但是内容似乎没有压缩。

我的想法已经不多了，我们将不胜感激。

byte [] bytes = rset.getBytes("CONTENTS");
     String str1 = new String(bytes);

System.out.println("str1 >> "+str1);

编辑：添加请求和响应标头

<filter>
  <filter-name>GzipFilter</filter-name>
  <filter-class>org.eclipse.jetty.servlets.GzipFilter</filter-class>
  <init-param>
     <param-name>mimeTypes</param-name>
     <param-value>text/html,text/plain,text/xml,application/xhtml+xml,text/css,application/javascript,application/json,image/svg+xml</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>GzipFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

Answer 1

--gzip ETag上的GzipFilter后缀用于了解请求处理是否实际通过了GzipFilter。

如果请求曾经被压缩过，那么它的目的是打破ETag DefaultServlet支持，现在不再被gzip压缩。

意思是这个流程：

使用gzip配置的服务器
请求资源/foo.js
DefaultServlet使用/foo.js

ETag: abcdef

GzipFilter配置为压缩application/javascript，因此压缩了响应并将ETag更改为ETag: abcdef--gzip
一段时间后，GzipFilter被重新配置（不同的url-pattern，不同的mime-types，无论如何）
相同的用户代理请求资源/foo.js与ETag: abcdef--gzip，但这不再通过GzipFilter，因此DefaultServlet将无法识别ETag并提供服务内容重新开始。

至于您的内容未被压缩的原因，可能是由于您设置response.setContentType()的方式或响应正文内容的大小。

首先，您需要确保在访问响应输出流（或编写器）之前始终设置响应状态代码，响应标头和（可选）响应缓冲区大小，如.getOutputStream()和.getWriter()都使用响应对象中的值来设置自己。

GzipFilter还使用这些值来了解是否应该压缩响应。

接下来，响应正文内容的大小很重要，因为在GzipFilter参与之前，响应大小有一个下限。（压缩GzipFilter.minGzipSize以下的大多数内容实际上效率低下）

在你的Jetty版本中，我相信minGzipSize是256个字节。

由于您的粘贴回复标题没有Content-Length和Transfer-Encoding: chunked，我无法确定您的回复实际有多大。


重要升级说明：Jetty 9.3+中的GzipFilter已被完全弃用，如果使用则会导致无操作。这是因为当使用Servlet 3.1和Async I / O时，Gzip压缩的过滤方法很成问题。

Jetty 9.3+中的Gzip支持已移出Servlet规范之外，并转换为低级HttpOutput.Interceptor模式，该模式仅在刷新发生后压缩内容（指定自动内部或应用程序）。

换句话说，servlet缓冲区不会被压缩，因为它们是从应用程序写入到Servlet缓冲区，如Jetty 9.2及之前的版本。它们只是在离开servlet缓冲区并进入网络级别写入时才被压缩。

Jetty-servlets GzipFilter不能与Jetty 9.2.7.v20150116和Spring一起使用

1 个答案: