What you could do (I basically asked the same question 1 week ago), is
that whenever you fastcgi_pass then enforce accept-encoding: gzip -
meaning you'll always request gzipped content from your backend - then
you can enable the gunzip directive by using "gunzip on;"
This means in case a client that does not support gzip compression,
nginx will uncompress the file on the fly - where rest of the requests
will be serving the file directly with a content-encoding: gzip - then
the supporting client will automatically do whatever it should.
First of all it saves you a bunch of storage and it should give you the
result you want. Serving (pre)compressed files to clients that support it.
--
Best Regards,
Lucas Rolff
seo010 wrote:
Hi *B. R.*!
Thanks a lot for the reply and information! The KEY however, does not
contain different data from http_accept_encoding. When viewing the contents
of the cache file it contains the exact same KEY for both MD5 hashes. Also,
it does not matter what browser is used for the first request. For example,
using a Google PageSpeed test at the first request will create the expected
MD5 hash for the KEY, and a next request using Chrome will create a new hash
for a file that contains the line "KEY: ..." that matches the KEY for the
first MD5 hash.
The third request also has a different KEY. I did not test any further, it
may be that the KEY will change for every new client. The KEY does remain
the same however for the same client. For example, the first request uses
the MD5 hash as expected for the KEY (as generated by MD5) and it will keep
using it in next requests.
As gzip compression causes a huge overhead on servers with high traffic, I
was wondering if Nginx would cache the gzip compressed result and if so, if
there is a setting with a maximum cache size. It would however, cause a
waste of cache space.
In tests the overhead added 4 tot 10ms on a powerful server for every
request compared with loading pre-compressed gzip HTML directly. It makes me
wonder what will be the effect on servers with high traffic.
As there appears to be no solution in Google, finding an answer may be
helpful for a lot of websites and it will make Nginx the best option for
full page cache.
Best Regards,
Jan Jaap
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,270604,270647#msg-270647
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
