rewritten javascript links are they meant to be gzip compressed / vary: accept-encoding enabled ?

[vbtechsupport]

I ran into a problem live testing ngx_pagespeed 1.5.27.2 beta with nginx 1.4.0.

Seems my javascript links rewritten have lost gzip and vary encoding headers. Is that the intended result with ngx_pagespeed ? As I read this old issue #53 which reads you wanted to strip gzip compression from rewritten js files ??

gtmetrix report
http://gtmetrix.com/reports/centminmod.com/cEbc74Dt

webpagetest.org reported header
http://www.webpagetest.org/result/130505_23_e698ca02e1da4c043d9014413c1fcedd/1/details/#request3

pagespeed online report

for vary: accept-encoding missing
https://developers.google.com/speed/pagespeed/insights#url=http_3A_2F_2Fcentminmod.com_2F_3FModPagespeed_3Don&mobile=false&rule=SpecifyAVaryAcceptEncodingHeader

gzip compression missing
https://developers.google.com/speed/pagespeed/insights#url=http_3A_2F_2Fcentminmod.com_2F_3FModPagespeed_3Don&mobile=false&rule=EnableGzipCompression

nginx.conf settings for gzip

    gzip on;
    gzip_vary   on;
    gzip_disable "MSIE [1-6]\.";
    gzip_static on;
    gzip_min_length   1100;
    gzip_buffers      32 8k;
    gzip_http_version 1.0;
    gzip_comp_level 5;
    gzip_proxied    any;
    gzip_types      text/plain text/css text/javascript text/xml application/x-javascript application/xml application/xml+rss;

for rewritten js links, should gzip and vary: accept-encoding be removed from the headers ?

[oschaaf]

@vbtechsupport we should be gzipping and sending out Vary response headers for javascript. However, we have seen other problems regarding this. Also, see the last few comments at #212 regarding gzip_types.

[oschaaf]

@vbtechsupport Looking in to this more, I think that just adding application/javascript to the list of gzip_types would help with getting your javascript files compressed.

[vbtechsupport]

yes i looked at #212 and tried adding application/javascript to the list, but still same problem for *.js rewritten files

I tried downgrading Nginx as well to from 1.4.0 and 1.2.8 and still same problem.

[oschaaf]

@vbtechsupport - sorry, looking at your response headers, it seems .js files are served out with content-type application/x-javascript; charset=utf-8. I think that also would need to be added to gzip_types to make it work.

[jeffkaufman]

@oschaaf but I do see application/x-javascript in @vbtechsupport's gzip_types. I don't think you need to put the charset in gzip_types if that's what you're saying.

I wonder if the problem here is that we're setting the content type somewhere but only partially. We had this problem before: #54.

[jeffkaufman]

(we do want to be serving rewritten resources gzipped)

[malir]

I have this problem too.
The rewritten js didn't compress.
This problem still in both 1.2.8 and 1.4.0 version of nginx.

[oschaaf]

@jeffkaufman "I don't think you need to put the charset in gzip_types if that's what you're saying."

I didn't think so either, but this is contradicted when experimentally changing mime.conf

    "application/x-javascript;charset=utf-8" js;
    #application/x-javascript              js;   

Looses the compression when gzip_types is set to:
gzip_types "application/x-javascript";

When changing gzip_types accordingly to:
gzip_types "application/x-javascript;charset=utf-8";

The responses for .js files are gzipped again.

[creativeprogramming]

I confirm that adding

gzip_types "application/x-javascript;charset=utf-8";

solved the problem also in my case, with it ".pagespeed." js responses are gzipped, without no.

PS i already had

gzip_types text/plain application/xhtml+xml text/css application/xml application/xml+rss text/javascript application/javascript application/x-javascript

but this wasn't enough

[oschaaf]

Adding gzip_types "application/x-javascript;charset=utf-8"; works around this, but like @jeffkaufman already suspected we should probably look in to if our module is behaving like a good nginx citizen here (maybe we need to separately tell nginx about the charset we are sending out in these content-type headers?).

Another thing which might work well is looking at mime.conf to see what content type we should send out for files served in these manner, as that probably is what gzip_types will target as well. Perhaps that would make configuring this more intuitive.

[malir]

Pay attention if your response header have a space in Content-Type,
you should consider in your config file.

[jeffkaufman]

With #362 this should be fixed in master and soon in release 1.5.27.3.

[jeffkaufman]

Released in 1.5.27.3

[vbtechsupport]

Updated to Nginx 1.4.2 and 1.6.29.5 beta and seems missing vary: accept encoding bug has returned ? Seem gtmetrix report at http://gtmetrix.com/reports/blog.centminmod.com/kIz3MPiL for Specify a Vary: Accept-Encoding header recommendation missing for both css and js files

wordpress blog has Google SPDY and ngx_pagespeed enabled