Open deweydb opened 8 years ago
Update, I disabled the filter: "combine_css" and now the gzip is working correctly for CSS. but it would be nice if i could leave that filter on.
eg: curl -H 'Accept-encoding: gzip' "https://bid13.com/sites/all/modules/admin_menu/A.admin_menu.css,q2.pagespeed.cf.SM_cpBMnRg.css"
returns gzipped content.
@deweydb When I add a real user-agent to the requests the css responses do get gzip-encoded:
$ curl -I -X GET "https://bid13.com/sites/A.all,,_modules,,_admin_menu,,_admin_menu.css,,q2+default,,_files,,_css,,_css_e95c6ea704b78c593760182162122319.css,Mcc.DBCpIWPb-N.css.pagespeed.cf.HegdJuwYto.css" -H "pragma: no-cache" -H "accept-encoding: gzip, deflate, sdch" -H "accept-language: en-US,en;q=0.8,nl;q=0.6" -H "upgrade-insecure-requests: 1" -H "user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36" -H "accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8" -H "cache-control: no-cache" -H "authority: bid13.com" --compressed
HTTP/1.1 200 OK
Server: nginx/1.9.12
...
Content-Encoding: gzip
Querying the same file without specifying a real browser user-agent, I can reproduce that there is no gzip compression applied to the response. @jeffkaufman do you know if this is a design choice around PageSpeed's capability for serving compressed .pagespeed. resources?
I cannot reproduce gzip compression for the webp image you posted, but I think that is a good thing. Gzip compression could potentially make the response for these images larger and would not provide any additional benefits.
Oh! so that makes a bit of sense then. The issue i ran into is that my CDN is proxying those files, and i don't think the CDN uses a real browser user agent to request from my server.
When I try this manually I'm getting non-gzipped body with "Content-Encoding: gzip" in the headers:
curl -D- -H 'Accept-encoding: gzip' "https://bid13.com/sites/A.all,,_modules,,_admin_menu,,_admin_menu.css,,q2+default,,_files,,_css,,_css_e95c6ea704b78c593760182162122319.css,Mcc.DBCpIWPb-N.css.pagespeed.cf.HegdJuwYto.css"
Server: nginx/1.9.12
Date: Fri, 04 Mar 2016 18:39:41 GMT
Content-Type: text/css
Content-Length: 33248
Connection: keep-alive
Last-Modified: Fri, 04 Mar 2016 18:17:38 GMT
X-Original-Content-Length: 184868
Content-Encoding: gzip
Vary: Accept-Encoding
Expires: Fri, 04 Mar 2016 18:22:38 GMT
X-Page-Speed: 1.10.33.6-0
Cache-Control: max-age=300,private
X-Proxy-Cache: MISS
Strict-Transport-Security: max-age=31536000
/**
* Administration Menu.
*
* Implementation of Sons of Suckerfish Dropdowns.
* @see www.htmldog.com/articles/suckerfish
**/
...
@jeffkaufman ... right. this is exactly my issue. But i don't know why this only happens when i have the 'combine_css' filter enabled?
@crowell could you look at this?
sure, i'll try to see what's up
curl -H 'Accept-encoding: gzip' "https://bid13.com/sites/A.all,,_modules,,_admin_menu,,_admin_menu.css,,q2+default,,_files,,_css,,_css_e95c6ea704b78c593760182162122319.css,Mcc.DBCpIWPb-N.css.pagespeed.cf.HegdJuwYto.css"
Gives a plaintext response.As otto points out that this should just work with no gzip settings at all in nginx: http://serverfault.com/questions/543009/how-do-i-enable-gzip-compression-on-nginx-pagespeed-module-resources#answer-659877
The issue seems to be specific to CSS, as images appear to work fine:
curl -H 'Accept-encoding: gzip' "https://bid13.com/sites/default/files/imagecache/product_list/290x165x129-1_0.png.pagespeed.ic.YuxZ0FXqYn.webp"
gives a gzipped response.
My guess is this might have something to do with mime.types, or gzip settings in nginx that i am overlooking. Currently my nginx gzip related settings are:
and my mime types are:
Interestingly enough the files stored within ngx_pagespeed cache appear to be gzip encoded.