Apache / Nginx / Varnish - GZIP does not work on css, js - apache

My current setup is as following:
Apache -> Nginx -> Varnish
running on Ubuntu
apache2.conf: h**p://pastebin.com/A3wehAbe
.htaccess: h**p://pastebin.com/Yre4hdSy (edited to allow deflate)
nginx.conf: h**p://pastebin.com/6X59CTAr (gzip enabled)
varnish: default settings
My problem is, it seems that GZIP only works with html content, not css or js.
I tested GZIP with this tool at:
http://www.gidnetwork.com/tools/gzip-test.php
h**p://rentsites.com.au
result: compressed yes
status HTTP/1.1 200 OK
server nginx/0.7.65
content-type text/html;
charset=UTF-8
x-powered-by PHP/5.3.2-1ubuntu4.22
x-pingback h**p://rentsites.com.au/xmlrpc.php
vary Accept-Encoding
content-encoding gzip
content-length 2281
accept-ranges bytes
date Mon, 13 Jan 201400:50:26 GMT
x-varnish 785049695 785049694
age 13
via 1.1 varnish
connection close
h**p://rentsites.com.au/wp-includes/js/jquery/jquery.js
result: compressed NO
status HTTP/1.1 200 OK
server nginx/0.7.65
content-type application/x-javascript
last-modified Wed, 21 Aug 2013 15:41:10 GMT
expires Mon, 12 Jan 2015 23:17:22 GMT
cache-control max-age=31536000, public
pragma public
content-length 93085
accept-ranges bytes
date Mon, 13 Jan 2014 00:27:30 GMT
x-varnish 785049693 785049631
age 4208
via 1.1 varnish
connection close
h**p://rentsites.com.au/wp-content/themes/twentyfourteen/genericons/genericons.css
result: compressed NO
status HTTP/1.1 200 OK
server nginx/0.7.65
content-type text/css
last-modified Tue, 12 Nov 2013 18:38:10 GMT
expires Mon, 12 Jan 2015 23:16:50 GMT
cache-control max-age=31536000, public
pragma public
content-length 22680
accept-ranges bytes
date Mon, 13 Jan 2014 00:52:38 GMT
x-varnish 785049696 785049621
age 5748
via 1.1 varnish
connection close
Please help. Thanks for reading.

Turns out that we need to add this to .htaccess:
AddType text/css .css
AddType text/javascript .js

Related

how to debug browser caching issue?

I have configured apache http with some cache settings. However, it does not seem to work properly and the browser seems to keep fetching the file as if it's not cached.
I tried to debug it by fetching the header.
$ curl -skI https://whatever-url-it-is/some-script.js
HTTP/1.1 200 OK
Date: Sun, 15 Sep 2019 05:35:08 GMT
Server: Apache/2.4.39 (Amazon) OpenSSL/1.0.2k-fips PHP/5.6.40
Last-Modified: Sun, 02 Jul 2017 10:52:25 GMT
ETag: "152ba-5535372162c40"
Accept-Ranges: bytes
Content-Length: 86714
Cache-Control: max-age=2592000, public
Expires: Tue, 17 Sep 2019 05:35:08 GMT
Vary: Accept-Encoding,User-Agent
Content-Type: text/javascript
The Cache-Control header seems to be correct. The Expires header looks a little odd but according to this page (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires) the Expire will be ignored given that Cache-Control is there.
What else can I do to debug this issue? Any idea is very well welcome. Thanks
Never mind. I didn't realized that "Disable Cache" was turned on in Chrome. User error :-)

Forcing Google Cloud storage to respond with Content-Encoding

I would like to serve some Unreal-generated HTML5 files using Google Cloud storage. Some of the files are gzip-encoded, and one of the javascript files checks that every file which ends with gz is returned with Content-Encoding: gzip. I don't want to change these files.
In GC UI, I set the Content-Encoding (and Content-type) fields in file metadata. To prevent decompressive transcoding I also set Cache-Control: no-transform. Despite that, the Content-Encoding header is still missing. (full header below). Is there anything else I can do to make Google Cloud respond with Content-Encoding?
HTTP/1.0 200 OK
X-GUploader-UploadID: some hash
Date: Sun, 24 Feb 2019 01:06:05 GMT
Cache-Control: no-transform
Expires: Mon, 24 Feb 2020 01:06:05 GMT
Last-Modified: Sun, 24 Feb 2019 00:52:29 GMT
x-goog-generation: 1550969549021835
x-goog-metageneration: 3
x-goog-stored-content-encoding: gzip
x-goog-stored-content-length: 99750206
Content-Type: application/octet-stream
x-goog-hash: crc32c=oobjmg==
x-goog-hash: md5=fN6srk43sVaYDVNgpXtdLQ==
x-goog-storage-class: REGIONAL
Accept-Ranges: none
Server: UploadServer
Vary: Accept-Encoding

HHVM + Apache + Varnish + Drupal 404

This seems like quite an odd thing to be happening, but I'm getting 404 responses but the pages are still displaying as expected.
I do have a slightly odd setup on this server, as we're running HHVM for PHP pages and using Varnish as we need to direct some of the pages to our old server.
We're running Drupal on this server and it seems to work fine except the 404 response seems to be stopping the login form from working.
I was going to add some images to show what's going on, but unfortunately don't have enough reputation....
here's the what we get from a GET -Sed request
pete#pete-work ~ $ GET -Sed http://beta.newint.org/user
GET http://beta.newint.org/user
404 Not Found
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Wed, 27 May 2015 15:14:23 GMT
Via: 1.1 varnish
Age: 0
Server: Apache
Vary: Accept-Encoding
Content-Language: en
Content-Type: text/html; charset=utf-8
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Client-Date: Wed, 27 May 2015 15:14:23 GMT
Client-Peer: 178.79.141.247:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
ImageToolbar: false
Link: <http://beta.newint.org/user>; rel="canonical",<http://beta.newint.org/user>; rel="shortlink"
Title: User account | Site-Install
X-Generator: Drupal 7 (http://drupal.org)
X-Meta-Charset: utf-8
X-Meta-Generator: Drupal 7 (http://drupal.org)
X-Meta-Viewport: width=device-width, maximum-scale = 1.0
X-Powered-By: HHVM/3.7.0
X-Varnish: 1786764394
And then bypassing varnish and going straight to apache
pete#pete-work ~ $ GET -Sed http://beta.newint.org:8080/user
GET http://beta.newint.org:8080/user
404 Not Found
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Wed, 27 May 2015 15:14:31 GMT
Server: Apache
Vary: Accept-Encoding
Content-Language: en
Content-Type: text/html; charset=utf-8
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Client-Date: Wed, 27 May 2015 15:14:32 GMT
Client-Peer: 178.79.141.247:8080
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
ImageToolbar: false
Link: <http://beta.newint.org:8080/user>; rel="canonical",<http://beta.newint.org:8080/user>; rel="shortlink"
Title: User account | Site-Install
X-Generator: Drupal 7 (http://drupal.org)
X-Meta-Charset: utf-8
X-Meta-Generator: Drupal 7 (http://drupal.org)
X-Meta-Viewport: width=device-width, maximum-scale = 1.0
X-Powered-By: HHVM/3.7.0
Any ideas?
Turns out this was simply due to mod_rewrite not being enabled.

How to configure Apache to send gzipped and chunked encoded response for static content?

For the purpose of unit testing, I want to configure Apache to gzip a static file and then chunk encode it and send it as a response. I tried following so far:
# Created a file httpd-deflate.conf
# Set to gzip all output
SetOutputFilter DEFLATE
#set compression level
DeflateCompressionLevel 9
# Deflate in chunks
DeflateBufferSize 100
Included this file in httpd.conf
Include httpd-deflate.conf
Send request as follows:
GET / HTTP/1.1
Host: test-server
Accept-Encoding: gzip
Connection: Keep-Alive
Got following response:
HTTP/1.1 200 OK
Date: Wed, 05 Nov 2014 19:24:23 GMT
Server: Apache/2.2.15 (Scientific Linux)
Last-Modified: Wed, 05 Nov 2014 18:17:21 GMT
ETag: "5e28c-5df-5072097390e40"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1186
Connection: close
Content-Type: text/html; charset=UTF-8
<binary-data>
Is there a way by which Apache can start sending the gziped data in chunked format. I thought DeflateBufferSize can help me do that. However, no luck so far.
Any suggestions?
Thanks.

Image Not Caching?

I'm convinced that certain images on my site are not caching properly. I have set the headers as best I can, but it still seems like they download again every time I hit the refresh button.
For example, a particular image always takes a bit over 1 second to download. This is even after it should be cached. Here are the response headers:
HTTP/1.1 200 OK
Date: Sun, 06 Mar 2011 12:51:52 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.7a mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.16
Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
Accept-Ranges: bytes
Content-Length: 19211
Cache-Control: max-age=630323456, public
Expires: Wed, 03 Mar 2021 12:51:52 GMT
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: image/png
Is there anything wrong with this? Thanks.
UPDATE
<FilesMatch "\.(htm|html|php)$">
Header set Expires "Thu, 01 Jan 1970 00:00:00 GMT"
</FilesMatch>
Your Last-Modified says 1970, and your max-age is 630323456 seconds (19 years). So the file has been 'expired' since 1989, and must be re-downloaded. The browser is doing what it should be doing.
Solution:
Change the Last-Modified to the real Last-Modified (probably some time in the past few years)
Change the max-age to
Remove the Expires header; it is overridden when you also have max-age. See RFC2616 section 14.9.3. Alternatively, delete the Cache-Control header and keep only the Expires header. Either one is fine, but only use one, not both of them.