Feature Request: Specify a Vary: Accept-Encoding header

[raamdev]

(Migrated this GitHub issue from an old repo.)

@ioerjfoige0439i writes...

---

Discovered this while running a test on http://zencache.com/features/ Please find these saved reports with the error below. W3 Total Cache doesn't produce this error when scanned on pages it's optimizing. Apparently it's as simple as adding some extra code to .htaccess (within a safe area of course as most people already have their own content in their .htaccess files).

A) http://gtmetrix.com/reports/zencache.com/ClT3KT8o
"Specify a Vary: Accept-Encoding header"
The following publicly cacheable, compressible resources should have a "Vary: Accept-Encoding" header:http://zencache.com/wp-content/cache/zencache/htmlc/public/zencache-com/1/9/5/a/f/f9823164268a8dcd6a6fce0cee440434-compressor-part.js

"Bugs in some public proxies may lead to compressed versions of your resources being served to users that don't support compression. Specifying the Vary: Accept-Encoding header instructs the proxy to store both a compressed and uncompressed version of the resource."

B) http://tools.pingdom.com/fpt/#!/bt2A6p/http://zencache.com/features/
"Specify a Vary: Accept-Encoding header"
The following publicly cacheable, compressible resources should have a "Vary: Accept-Encoding" header: http://zencache.com/wp-content/cache/zencache/htmlc/public/zencache-com/1/9/5/a/f/f9823164268a8dcd6a6fce0cee440434-compressor-part.js

I've seen some suggestion to fix this such as:

http://www.fastly.com/blog/best-practices-for-using-the-vary-header/

or here:

http://httpd.apache.org/docs/2.0/mod/mod_deflate.html

or here:

http://stackoverflow.com/questions/3641197/how-to-specify-vary-accept-encoding-header-in-htaccess

here's what I have in my .htaccess (which btw could be wrong as I wrote this a long time ago and am running the vary accept code twice because I don't know proper apache code lol):

<IfModule mod_deflate.c>

 <IfModule mod_headers.c>
  Header append Vary User-Agent env=!dont-vary
 </IfModule>

 AddOutputFilterByType DEFLATE text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/json

 <IfModule mod_mime.c>
   # DEFLATE by extension
   AddOutputFilter DEFLATE js css htm html xml
 </IfModule>

</IfModule>

<IfModule mod_headers.c>

 <FilesMatch "\.(js|css|xml|gz)$">
  Header append Vary: Accept-Encoding
 </FilesMatch>

</IfModule>

[jaswrks]

Referencing: https://www.maxcdn.com/blog/accept-encoding-its-vary-important/

[jaswrks]

@raamdev I'm referencing this section of the article on Apache's mod_deflate.
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html#proxies

I conclude from that article, that using mod_deflate (recommended) will automatically enable Vary: Accept-Encoding. Therefore, a snippet like this, together with AddOutputFilterByType DEFLATE would be unnecessary. Can you please check me on that by reading over the article above? I just ran a few tests and it seems so.

<IfModule mod_headers.c>

 <FilesMatch "\.(js|css|xml|gz)$">
  Header append Vary: Accept-Encoding
 </FilesMatch>

</IfModule>

---

I'm opening another issue for the HTML Compressor that is related to this. For servers that are not using mod_deflate, we could force this header through an auto-generated .htaccess file in the public cache directory for the HTML Compressor. Seem like a good idea?

Referencing: wpsharks/html-compressor#55

---

Generally speaking, I don't see any harm coming from Vary: Accept-Encoding. So adding that as a suggestion for any Nginx or Apache config file examples seems like a good idea to me.

---

Finally, thank you for bringing this to my attention. I did not realize the impact of Vary: Accept-Encoding until I reviewed this issue. I'd also like to apologize to @ioerjfoige0439i for sort of dismissing this the first time I saw it. Thanks for bringing this up! :-)

[raamdev]

I conclude from that article, that using mod_deflate (recommended) will automatically enable Vary: Accept-Encoding. Therefore, a snippet like this, together with AddOutputFilterByType DEFLATE would be unnecessary. Can you please check me on that by reading over the article above? I just ran a few tests and it seems so.

I read over the article you referenced and I concur.

I'm opening another issue for the HTML Compressor that is related to this. For servers that are not using mod_deflate, we could force this header through an auto-generated .htaccess file in the public cache directory for the HTML Compressor. Seem like a good idea?

Yep, that sounds like a good idea to me.

---

@jaswsinc Does closing wpsharks/html-compressor#55 close this issue? It would appear so, but I want to make sure I'm not missing anything here.

[jaswrks]

@raamdev writes...

Does closing wpsharks/html-compressor#55 close this issue?

Yes, sure does.

[ioerjfoige0439i]

@jaswsinc no problem, I am really trying to help you guys out here lol, no hard feelings. I'm just passionate about my job.

[raamdev]

Next release changelog:

• Enhancement (Pro): Files being served by the HTML Compressor were not setting a Vary: Accept-Encoding header, which caused some page speed testing services to give a lower rating to sites using ZenCache. ZenCache now sends this header via an .htaccess file inside the HTML Compressor cache directory (requires Apache 2.1+). Issue #436.

[ioerjfoige0439i]

Question @raamdev @jaswsinc do we have to enable the HTML Compressor for this to be placed in the .htaccess? I ask because I am already using a separate HTML Compression plugin which works extremely well in conjunction with zencache and s2member and I don't want to switch http://codecanyon.net/item/dynamic-website-compressor/2838376

[raamdev]

@ioerjfoige0439i These changes only apply to ZenCache and the ZenCache HTML Compressor.

[ioerjfoige0439i]

ok thanks. so I can still use my compression plugin and receive the benefits of this enhancement right?

[jaswrks]

@ioerjfoige0439i writes...

do we have to enable the HTML Compressor for this to be placed in the .htaccess?

Yes. The HTML Compressor generates JS/CSS part files and stores them in a special directory for public consumption. That directory now contains a new .htaccess file with the following:

<IfModule authz_core_module>
    Require all granted
</IfModule>
<IfModule !authz_core_module>
    allow from all
</IfModule>

<IfModule headers_module>
    <FilesMatch "\.(html|js|css)$">
        Header append Vary: Accept-Encoding
    </FilesMatch>
</IfModule>

If you want to use Vary: Accept-Encoding for all HTML/JS/CSS files on your site you can add this section to your root .htaccess file; i.e., the one that also contains your WordPress rewrite rules.

<IfModule headers_module>
    <FilesMatch "\.(html|js|css)$">
        Header append Vary: Accept-Encoding
    </FilesMatch>
</IfModule>

Tip: You can modify the list of extensions by adding new ones to the pipe-delimited list if you like; e.g., html|js|css|txt|svg|xml

Tip: Keep in mind that you don't need to do this if you're already using the mod_deflate module in Apache. In other words, if you are using the .htaccess entry suggested by ZenCache for enabling GZIP compression, GZIPd files already get Vary: Accept-Encoding, because it is built into the Apache module itself. See: http://httpd.apache.org/docs/2.0/mod/mod_deflate.html#proxies

[raamdev]

This fix has been released with ZenCache v150409:
http://zencache.com/zencache-v150409-now-available/

If you need to follow-up with something related to this GitHub Issue, please open a new GitHub Issue.