Remember the solution to the problem of Nginx Ngx_http_substitutions_filter_module not working properly

Because the project needs to use Nginx to do reverse proxy, you need to do some replacement of the content returned from the source station, these contents are html,css, and JS, etc., Nginx ngx_http_sub_module module can realize the function of replacing, However, compared to the Yaowenbin developed by the Ngx_http_substitutions_filter_module, the function is slightly weaker: 1, does not support case sensitivity, 2, does not support regular expressions, 3, does not support the substitution of multiple strings (ngx_http_ Sub_module supports this feature starting from version 1.9.4).

But in the use of Ngx_http_substitutions_filter_module to find the content of HTML can be replaced, but the Js\css file is not replaced, I will respone body content copied to another server, and then do the reverse generation, Found that there is no problem and can work properly.

My core profile is as follows (disabled gzip compression has been set)

location/demo/{proxy_pass http://192.168.1.2proxy_set_header accept-encoding '; subs_filter src_string dst_string; Subs_filter_types *;p roxy_redirect off;}

After nearly two days of troubleshooting, tried to upgrade the Nginx version of a series of operations, and did not solve my problem.

Finally can only use Nginx Debug function to troubleshoot, found the debug log as follows:

2016/05/20 10:47:59 [Debug] 390#0: * HTTP Proxy header: "content-encoding:gzip" 2016/05/20 10:47:59 [warn
     ] 390#0: * * HTTP Subs filter header ignored, this could be a compressed response. While reading response headers from upstream, client:192.168.1.2, server:demo.xxxx.com, Request: "get/demo/login.js http/1.1", upstream:"http://192.168.1.2:80/demo/login.js", Host:"demo.xxxx.com"

The log reflects two issues: 1, the HTTP header of the response is compressed using gzip format, 2, the content of the response may be compressed, the HTTP Subs filter module is ignored, not processed! The original source station returned JS and CSS content is still compressed, but I have set the Proxy_set_header accept-encoding "Ah? Why is the returned content still compressed? Decide to use the Wireshark capture package to view the underlying packets.

From the packet, the header of the request is indeed set to not compress, but the content returned is still compressed, it appears that the problem is in the source site of the Web server.

Source control station Administrator verification, get the result is: JS and CSS files have been compressed, so regardless of whether the request is received compression, the content returned is compressed, this cannot be modified.

Source station can not be modified, only from Nginx here to find a way, but nginx replacement must not be decompressed, this is not easy to do.

Groping found this article: Nginx anti-Gzip content, Sub_filter and other content filter invalid another solution

Although more than one request, but more save network bandwidth resources. Due to the use of the Gunzip module decompression, can only re-compile nginx (This troubleshooting problem, recompile 10 times more than AH).

The article uses the UNIX socket way, but from some Netizen's test, does not like the TCP socket stability (PHP-FPM Tcpsocket vs unixsocket), I think still uses listens the TCP port the way. The final configuration is as follows:

location/demo-gzip/{        proxy_pass http://192.168.1.2/; Gunzip on;        Allow 127.0.0.1/32;        Deny all;} location/demo/{        proxy_pass http://127.0.0.1/t5060-gzip/; Proxy_set_header Host demo.xxxx.com;proxy_set_header accept-encoding "; Subs_filter src_string Dst_string;subs_ Filter_types application/javascript Text/css;}

Remember the solution to the problem of Nginx Ngx_http_substitutions_filter_module not working properly