如何解决nginx对gzip压缩的弱etags转换问题

Question

我试图在nginx中使用gzip来压缩某些端点的响应主体。问题在于nginx标记上游应用程序生成的etags为弱（前缀为“W /”）。上游应用程序还没有弱etag支持（春季版本<4.3）。当客户发回弱etag时，它与app计算的强etag不匹配，我没有看到304状态而是200身体。即使应用程序的etag较弱，在一个层中管理压缩比修改所有应用程序更容易，现在升级它们并启用弱标记。

我正在尝试两种选择：

1. 当上游服务器发送强etag并且nginx gzip将其修改为弱etag时，请尝试使用nginx lua API将其修改为strong。
2. 当客户端发回弱etags时，剥去弱etag标识符（“W /”）并将请求转发给应用程序。

我必须在nginx配置和lua API使用中做错了，我无法实现这一点。此问题与选项1有关。

Nginx配置：

  location /test/compression {
  proxy_pass              http://upstream_server:8080/someapi;
  proxy_redirect          default;
  proxy_set_header        X-Real-IP               $remote_addr;
  proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;

  include compression.conf;

  header_filter_by_lua_block {
          ngx.header["ETag"] = string.substring(ngx.header["ETag"], 2);
      }
  }

compression.conf

gzip on;
gzip_http_version 1.0;
gzip_proxied any;
gzip_types application/json application/octet-stream;
gzip_min_length 10000;
gzip_comp_level 7;

实际结果：nginx日志中出错：

nginx  | 2019/03/21 14:11:06 [error] 38#38: *8 failed to run header_filter_by_lua*: header_filter_by_lua:2: attempt to call field 'substring' (a nil value)
nginx  | stack traceback:
nginx  |    header_filter_by_lua:2: in function <header_filter_by_lua:1> while reading response header from upstream, client: 127.0.0.1, server: _, request: "GET /test/compression HTTP/1.1", upstream: "http://upstream_server:8080/someapi", host: "localhost:9696"

预期结果：对客户的回应强烈的ETag

还尝试了另一种方法来检索ETag标题后：nginx - read custom header from upstream server

  location /test/compression {
  proxy_pass              http://upstream_server:8080/someapi;
  proxy_redirect          default;
  proxy_set_header        X-Real-IP               $remote_addr;
  proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;

  include compression.conf;
  set $etag $upstream_http_etag

  header_filter_by_lua_block {
          ngx.header["ETag"] = string.substring(ngx.var.etag, 2);
      }
  }

同样的错误。

Answer 1

最后，我最终修改了客户端的“If-None-Match”请求标头。

1. 如果客户端在“If-None-Match”请求标头中发送了弱etag，请使用lua或set nginx指令在nginx重写阶段将其修改为强etag。
2. 如果客户端在“If-None-Match”请求标头中发送了强etag，请保持原样。
3. 如果来自上游的304响应，则不会调用nginx gzip模块，并且强etag会返回到客户端。 Ti处理这个我离开了header_filter_by_lua_block块，因此对304响应做了强到弱的etag转换。

这个解决方案对我有用。欢迎以更好的方式做任何建议。