<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">$http_accept_encoding gets the value of the HTTP Accept-Encoding header.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">This might vary depending on the client being used, unless you control them and their value.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Thus, the same request being made with a different (set of) value(s) in this header will generate another key.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">If you simply want to check a specific value is being used in this header, you might filter its content through a (series of) map and used the filtered values only as part of a cache key.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That is a quick idea, I have put much brains in it, but it could be a step in the direction you want to go.<br></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Thu, Oct 27, 2016 at 8:41 PM, seo010 <span dir="ltr"><<a href="mailto:nginx-forum@forum.nginx.org" target="_blank">nginx-forum@forum.nginx.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I was wondering if anyone has an idea to serve pre-compressed (gzip) HTML<br>
using proxy_cache / fastcgi_cache.<br>
<br>
I tried a solution with a map of http_accept_encoding as part of the<br>
fastcgi_cache_key with gzip compressed output from the script, but it<br>
resulted into strange behavior (the MD5 hash for the first request<br>
corresponds to the KEY, the next requests with an unknown MD5 hash using the<br>
same KEY.<br>
<br>
Nginx version: 1.11.1<br>
<br>
The initial solution to serve pre-compressed gzip HTML from proxy_cache /<br>
fastcgi_cache was the following:<br>
<br>
Map:<br>
map $http_accept_encoding $gzip_enabled {<br>
    ~*gzip                gzip;<br>
}<br>
<br>
Server:<br>
fastcgi_cache_path /path/to/cache/nginx levels=1:2 keys_zone=XXX:20m<br>
max_size=4g inactive=7d;<br>
<br>
PHP-FPM proxy:<br>
set $cache_key "$gzip_enabled$request_method$<wbr>request_uri";<br>
<br>
fastcgi_pass unix:/path/to/php-fpm.sock;<br>
fastcgi_index index.php;<br>
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_<wbr>name;<br>
fastcgi_param PHP_VALUE "error_log=/path/to/logs/php.<wbr>error.log";<br>
fastcgi_intercept_errors on;<br>
<br>
# full page cache<br>
fastcgi_no_cache $skip_cache_save;<br>
fastcgi_cache_bypass $skip_cache;<br>
fastcgi_cache XXX;<br>
fastcgi_cache_use_stale error timeout invalid_header updating http_500;<br>
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;<br>
fastcgi_cache_valid 200 7d; # valid for 7 days<br>
fastcgi_cache_valid 301 302 304 1h;<br>
fastcgi_cache_valid any 5m;<br>
fastcgi_cache_lock on;<br>
fastcgi_cache_lock_timeout 5s;<br>
fastcgi_cache_key $cache_key;<br>
<br>
add_header X-Cache $upstream_cache_status;<br>
#add_header X-Cache-Key $cache_key;<br>
<br>
include fastcgi_params;<br>
<br>
It did work when testing in 1 browser: it showed "MISS" and "HIT" for 2<br>
requests. The cache directory showed the correct MD5 hash for the key.<br>
<br>
But when testing the same URL again in a different browser, a yet<br>
unexplained behavior occurred. A totally new MD5 hash was used to store the<br>
same pre-compressed content. When viewing the cached file, the exact same<br>
KEY was shown (without additional spaces or special characters).<br>
<br>
Although the solution with a GZIP parameter may work, I was wondering if<br>
anyone knows of a better solution to serve pre-compressed HTML from Nginx<br>
cache as it results into 4 to 10ms latency saving per request on a idle<br>
quad-core server with 4x SSD in RAID 10.<br>
<br>
I could not find any information related to a solution in Google while it<br>
appears to be a major potential for performance gain on high traffic<br>
websites.<br>
<br>
Best Regards,<br>
Jan Jaap<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,270604,270604#msg-270604" rel="noreferrer" target="_blank">https://forum.nginx.org/read.<wbr>php?2,270604,270604#msg-270604</a><br>
<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</blockquote></div><br></div></div>