在ProxyPass中使用Nginx时，Apache会丢弃ETag标头

问题描述 投票：1回答：1

今天是个好日子。当我使用从Apache到Nginx的ProxyPass时，我只是注意到了相当奇怪的行为，让我演示并询问是否有人遇到过类似的东西。

最小的设置是这样的：

阿帕奇：

LogLevel trace6

SSLProxyEngine On
SSLProxyCheckPeerName Off
SSLProxyCheckPeerCN Off

<LocationMatch "\.js$">
    ProxyPassMatch https://static-assets.dev.com:4430
    ProxyPassReverse https://static-assets.dev.com:4430
</LocationMatch>

Nginx的：

server {
    listen *:4430 default_server ssl;

    ssl_certificate     /etc/nginx/ssl/ssl.crt;
    ssl_certificate_key /etc/nginx/ssl/ssl.key;

    server_name static-assets.dev.com;

    root /assets;

    etag on;
    gzip off;

    server_tokens off;

    add_header X-Hi-From-Nginx $sent_http_etag;

    location / {
        try_files $uri $uri/ =404;
    }
}

然后在Apache日志中我看到：

[Thu Feb 21 14:49:18.762737 2019] [proxy_http:trace3] [pid 895:tid 139989845219072] mod_proxy_http.c(1424): [client 172.17.0.1:40486] Status from backend: 200
[Thu Feb 21 14:49:18.762744 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1099): [client 172.17.0.1:40486] Headers received from backend:
[Thu Feb 21 14:49:18.762749 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] Server: nginx
[Thu Feb 21 14:49:18.762752 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] Date: Thu, 21 Feb 2019 06:49:18 GMT
[Thu Feb 21 14:49:18.762759 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] Content-Type: application/javascript
[Thu Feb 21 14:49:18.762762 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] Content-Length: 1130146
[Thu Feb 21 14:49:18.762765 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] Last-Modified: Mon, 18 Feb 2019 05:11:04 GMT
[Thu Feb 21 14:49:18.762768 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] Connection: keep-alive
[Thu Feb 21 14:49:18.762771 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] ETag: "5c6a3e68-113ea2"
[Thu Feb 21 14:49:18.762773 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] X-Hi-From-Nginx: "5c6a3e68-113ea2"
[Thu Feb 21 14:49:18.762776 2019] [proxy_http:trace4] [pid 895:tid 139989845219072] mod_proxy_http.c(1101): [client 172.17.0.1:40486] Accept-Ranges: bytes
[Thu Feb 21 14:49:18.762783 2019] [proxy_http:trace3] [pid 895:tid 139989845219072] mod_proxy_http.c(1695): [client 172.17.0.1:40486] start body send

[Thu Feb 21 14:49:18.762837 2019] [http:trace3] [pid 895:tid 139989845219072] http_filters.c(1129): [client 172.17.0.1:40486] Response sent with status 200, headers:
[Thu Feb 21 14:49:18.762841 2019] [http:trace5] [pid 895:tid 139989845219072] http_filters.c(1136): [client 172.17.0.1:40486]   Date: Thu, 21 Feb 2019 06:49:18 GMT
[Thu Feb 21 14:49:18.762844 2019] [http:trace5] [pid 895:tid 139989845219072] http_filters.c(1139): [client 172.17.0.1:40486]   Server: nginx
[Thu Feb 21 14:49:18.762847 2019] [http:trace4] [pid 895:tid 139989845219072] http_filters.c(958): [client 172.17.0.1:40486]   Content-Type: application/javascript
[Thu Feb 21 14:49:18.762849 2019] [http:trace4] [pid 895:tid 139989845219072] http_filters.c(958): [client 172.17.0.1:40486]   Content-Length: 1130146
[Thu Feb 21 14:49:18.762852 2019] [http:trace4] [pid 895:tid 139989845219072] http_filters.c(958): [client 172.17.0.1:40486]   Last-Modified: Mon, 18 Feb 2019 05:11:04 GMT
[Thu Feb 21 14:49:18.762854 2019] [http:trace4] [pid 895:tid 139989845219072] http_filters.c(958): [client 172.17.0.1:40486]   X-Hi-From-Nginx: \\"5c6a3e68-113ea2\\"
[Thu Feb 21 14:49:18.762857 2019] [http:trace4] [pid 895:tid 139989845219072] http_filters.c(958): [client 172.17.0.1:40486]   Accept-Ranges: bytes
[Thu Feb 21 14:49:18.762859 2019] [http:trace4] [pid 895:tid 139989845219072] http_filters.c(958): [client 172.17.0.1:40486]   Vary: Accept-Encoding

所以基本上它丢弃了ETag标头，但是我的自定义X-Hi-From-Nginx标头具有相同的值而没有任何问题。我读到Nginx在启用gzip时可能会遇到一些ETag问题，但是禁用它并不会改善任何东西。事实上，很明显问题出在Apache端，因为Nginx会按预期发送所有头文件。

这是我正在使用的软件（通过Docker）：

root@7ac07b106612:/bootstrap# nginx -v
nginx version: nginx/1.10.3 (Ubuntu)
root@7ac07b106612:/bootstrap# apache2ctl -v
Server version: Apache/2.4.18 (Ubuntu)
Server built:   2018-06-07T19:43:03

第二天更新..

我实际设法使用expr设置另一个自定义标头，如下所示：

Header always set X-Apache-ETag "expr=%{resp:x-nginx-etag}"
Header always set ETag "expr=%{resp:x-nginx-etag}"

但是它只设置“X-Apache-ETag”标头，而ETag仍然被丢弃。它开始看起来像一些bug ..

> GET /dist/js/vendor.js HTTP/1.1
> Host: dev.com
> User-Agent: curl/7.53.0
> Accept: */*
> Accept-encoding: br
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Date: Fri, 22 Feb 2019 04:55:10 GMT
< Server: nginx
< X-Apache-ETag: "5c6f3469-4ad21"
< Content-Type: application/javascript
< Content-Length: 306465
< Last-Modified: Thu, 21 Feb 2019 23:29:45 GMT
< X-Nginx-Etag: "5c6f3469-4ad21"
< Accept-Ranges: bytes
< Vary: Accept-Encoding

更新＃2。几个细节..我看到它说“http_filters.c”附近“响应发送状态200，标题：”，所以我开始谷歌搜索该文件的来源。而here就是我发现的：

/*
 * Now remove any ETag response header field if earlier processing
 * says so (such as a 'FileETag None' directive).
 */
if (apr_table_get(r->notes, "no-etag") != NULL) {
    apr_table_unset(r->headers_out, "ETag");
}

不知道为什么这个条件会触发，因为我的配置中没有“FileETag None”。即使我添加“FileETag MTime Size”也无济于事。

apache nginx proxypass etag
1个回答
0
投票

更新＃3 ..

我认为这是由加载的“包含”模块引起的。它具有这个特定的SSIETag指令，默认设置为“关闭” - 基于导致“no-etag”音符的描述和最终消失的标题。

在上下文中将其设置为“On”并没有多大帮助，但是禁用“include”模块完全有帮助，所以这就是罪魁祸首。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.