Browser Cache Issue - symfony

I have a Symfony2 app using assetic. Everything is fine except that in localhost my assetic assets does not get cached by browser.
Any idea why the following assets does not get served cached with response 304 and in milliseconds but instead with 200 response and takes about 15 seconds....
Response Headers
Accept-Ranges bytes
Cache-Control max-age=604800
Connection Keep-Alive
Content-Encoding gzip
Content-Type application/javascript
Date Fri, 20 Mar 2015 13:26:55 GMT
Etag "159d57-511b83723ef71-gzip"
Expires Fri, 27 Mar 2015 13:26:55 GMT
Keep-Alive timeout=5, max=100
Last-Modified Fri, 20 Mar 2015 13:23:00 GMT
Server Apache/2.4.9 (Win64) PHP/5.5.12
Transfer-Encoding chunked
Vary Accept-Encoding
Request Headers
Accept text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Cache-Control max-age=0
Connection keep-alive
Cookie XDEBUG_SESSION=16069
Host localhost
If-Modified-Since Fri, 20 Mar 2015 13:23:00 GMT
If-None-Match "159d57-511b83723ef71-gzip"
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Even if I go directly to this file through browser and then press F5 cache is not working.... But instead in other files i get 304 instead of 200...

I am sorry for trouble, problem was the Apache deflate bug when using ETAGs. By disabling ETAGs its working fine and returns 304.

Related

Servlet response ETag Cache

I want to use ETag to cache the version of a request and return 304 not modifed response to the client so the client can use last cached page.
So my url is like this which returns a json response
"http://server/WEB_GWT/prmCall?prmName=PRM_SIS_PROG_REG_STATUS"
In my servlet handling this request, I am always putting ETag information to store its value to be the version of url param PRM_SIS_PROG_REG_STATUS.
So response header returning to client is
HTTP/1.1 200 OK
Date: Sat, 07 Dec 2013 16:07:49 GMT
Server: IBM_HTTP_Server
ETag: "5"
Last-Modified: Sat, 07 Dec 2013 16:07:49 GMT
Content-Length: 356
Keep-Alive: timeout=10, max=99
Connection: Keep-Alive
Content-Type: application/json
Content-Language: tr-TR
In my next request, I am expecting this request header to include "If-None-Match" header to return the version of the request but I cannot get this header param. Any idea why I cannot get my ETag back.
My next request header is
GET /OZU_GWT/prmCall?prmName=PRM_SIS_PROG_REG_STATUS HTTP/1.1
Host: 10.100.199.103
Connection: keep-alive
Cache-Control: max-age=0
If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
Accept: */*
Referer: http://10.100.199.103/OZU_GWT/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: JSESSIONID=0000kvocMBmjoWPbpKt_VAsDUMv:-1
Inoder to cache your request you need to include "Cache-Control" directive and specify the way in which the response should be cached and for what period.
HTTP/1.1 200 OK
Date: Sat, 07 Dec 2013 16:07:49 GMT
Server: IBM_HTTP_Server
ETag: "5"
Cache-Control : public, max-age=86400
Content-Length: 356
Keep-Alive: timeout=10, max=99
Connection: Keep-Alive
Content-Type: application/json
Content-Language: tr-TR
Here the Cache-Control header says that the content can be stored by "public" caching servers and the duration after which it needs to revalidate the content is 86400 seconds. And so when you refresh the page again "If-None-Match" and "If-Modified-Since" conditional headers will kick in and use the cached data.
After some investigation,I found out SmartGWT framework requests are sent to server with bypassCache:true flag which was sending my xhr request without any cache header. I managed to fixed it by overriding following method in DataSource class.
#Override
protected Object transformRequest(DSRequest dsRequest) {
dsRequest.setBypassCache(false);

Why are browsers not caching these static files

my question seems duplicate of this
but I am having a case
when I refresh a page with F5 then images are not getting fetched from cache instead request is going to server and server responding 304 status code(not modified)
but if I type a URL in address-bar or navigate page from browser back/forward button then images are coming from cache.
but I am having one doubt here why request is made for cached images to origin server on F5 (page refresh)
Nginx configuration
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 2d;
proxy_pass http://localhost:3001;
break;
}
Request header
===================================
GET /assets/first_banner.png HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36
Referer: http://localhost:3000/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
===================================
Response header:
===================================
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Sun, 08 Dec 2013 20:31:06 GMT
Content-Type: image/png
Content-Length: 141498
Connection: keep-alive
Cache-Control: max-age=172800
Last-Modified: Wed, 23 Oct 2013 05:34:11 GMT
Etag: "0fc96d0218a47398d37dacca76916727"
X-Ua-Compatible: IE=Edge
X-Request-Id: 48d1ec3a24e2c0f13250ea74101f6753
X-Runtime: 0.021479
Expires: Tue, 10 Dec 2013 20:31:06 GMT
===================================
When you hit F5 you tell the browser to check the webserver if the content, cached locally or not, is still valid.
If the object is expired on the webserver then the browser fetch the asset again. If the object is still valid, the local browser-cached content is used.

LiveHttpHeaders: which cache-control info is right

Using LiveHttpHeaders for Firefox 6 I was trying to see if my css, JS files being cached using Headers Module from Apache using htaccess. But I confuse, there are 2 values from the 'Cache-Control' data:
GET /proz/css/global.css HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://localhost/proz/
Cookie: PHPSESSID=el34de37pe3bnp4rdtbst1kd43
If-Modified-Since: Fri, 16 Sep 2011 21:15:32 GMT
If-None-Match: "400000000b06a-2999-4ad157e5b4583"
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Date: Sat, 17 Sep 2011 03:04:50 GMT
Server: Apache/2.2.17 (Win32) PHP/5.2.8
Connection: Keep-Alive
Keep-Alive: timeout=5, max=99
Etag: "400000000b06a-2999-4ad157e5b4583"
Cache-Control: max-age=604800, public
Vary: Accept-Encoding
Which one is the true data, the first Cache-Control data (max-age=0) or the latter one.
I also would like to know how do I make sure that my JS, CSS, HTML files being compress after I use deflate module in htaccess. And yes, both headers and deflate modules are turn on.
There are two parts in this listing:
The part before the blank line is the request, sent by your browser
The part after the blank line is the response, sent by the server
The Cache-Control: max-age=0 sent by the client (your browser) tells the server (or any proxy in the middle) to send the most fresh version of the file. The browser usually sends this when you hit the refresh button.
The Cache-Control: max-age=604800, public sent by the server tells the client (your browser or a proxy) that the file is valid for 604800 seconds and can be cached for that time. (The browser won't even attemps to ask the server if a newer version exists, unless you hit refresh, as you did in this case.)
The server replied 304 Not Modified, this means that your browser already has the most recent version and it doesn't need to download it again (it did not downloaded it again).
The Vary: Accept-Encoding header indicate that the server taken some decisions based on the client's Accent-Encoding header. This may indicate that, if the server didn't replied 304 Not Modified, it would have compressed the file.
To verify this last point, clear your cache, and request the file again, and look at the content of the Content-Encoding header (must be gzip or deflate if the data is compressed).

Firefox & IE: Corrupted data when retrieved from cache

I have a request to the server which looks like this:
http://localhost/Combine.aspx/flag/file1.js,file2.js,file3.js
I have also tried this:
http://localhost/Combine.aspx/flag/value/file1.js/file2.js/file3.js
It simply combines the three files which it was given: this works fine.
Upon the first request from Firefox, the page displays correctly. When the page is refreshed again, the content looks like this:
��������`I�%&/m�{J�J��t��`$�����iG#)�*��eVe]f#�흼��{���{��;�N'
In that case, no request is made to the server, the file is only retrieved from the firefox cache, as far as I can tell.
If I force-refresh the page with Control-F5, the page looks normal again.
Here is the request and response (in firebug) with Control-F5 (works):
Response
Cache-Control public
Content-Type application/javascript; charset=utf-8
Content-Encoding gzip
Expires Sun, 26 Feb 2012 02:57:26 GMT
Last-Modified Fri, 07 Jan 2011 21:08:54 GMT
Etag CLYvZwbFmainWEMi8h-6x-zNEIQ1
Vary Accept-Encoding
Server Microsoft-IIS/7.5
Set-Cookie auth=longstring; path=/
X-AspNet-Version 2.0.50727
X-Powered-By ASP.NET
Date Thu, 03 Mar 2011 02:57:26 GMT
Content-Length 918
Request
Host localhost
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14) Gecko/20110218 Firefox/3.6.14
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Cookie auth=longstring
Pragma no-cache
Cache-Control no-cache
Here is the same with just F5 (doesn't work):
Response:
Cache-Control public
Content-Type application/javascript; charset=utf-8
Content-Encoding gzip
Expires Sun, 26 Feb 2012 02:57:26 GMT
Last-Modified Fri, 07 Jan 2011 21:08:54 GMT
Etag CLYvZwbFmainWEMi8h-6x-zNEIQ1
Vary Accept-Encoding
Server Microsoft-IIS/7.5
X-AspNet-Version 2.0.50727
X-Powered-By ASP.NET
Date Thu, 03 Mar 2011 03:01:31 GMT
Content-Length 1533
Request:
Host localhost
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14) Gecko/20110218 Firefox/3.6.14
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Cookie auth=longstring
The only thing that I can tell is different is the Content-Length (which is likely causing the corruption), but since it never hits the server, I have no control over it.
What could be causing this?
Edit:
This happens on IE8 as well, but instead of viewing a corrupt file, it downloads the corrupt file. No request is ever made to the server (set a breakpoint in visual studio).
As for chrome, when viewing the url directly, a request to the server is made every time, and it works every time. I believe, though, that if it were included in a tag, it would behave similar to Firefox.
Oh, and also:
If I turn off the Expires header (which is one of the flags in the URL), everything works fine.
Edit 2:
I was able to work around this by not sending both an Expires and ETag header, only one or the other. I have no clue why an ETag header would cause such corruption, though.
It is because of your IIS configuration. Adjust IIS as ASP 4.0 Classic, not Default Application Pool

IIS6 not doing gzip compression when including Via header in request

I have some static content going through a CDN. I am using IIS6's built in compression (gzip & deflate) for static content and this is working fine when I request it. However, when the CDN makes the initial request for the content, it is not being returned compressed. They therefore don't have compressed content to forward to people requesting it. (Yes this raises the issue of people requesting [the zipped] content from the CDN with a browser that can't handle the compression. - We'll put that to one side for now though)
Here's an example of requesting without the 'Via' header:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
accept-encoding: gzip
And it returns a compressed response:
HTTP/1.1 200 OK
Content-Length: 4357
Content-Type: application/x-javascript
Content-Encoding: gzip
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:52 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:27:50 GMT
However, if I include a 'Via' header in the request (as the CDN does) then the result comes back uncompressed:
Request:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
Via: 1.1 204.160.105.17:80 (Footprint 4.5/FPMCP)
accept-encoding: gzip
Response:
HTTP/1.1 200 OK
Content-Length: 14602
Content-Type: application/x-javascript
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:54 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:29:52 GMT
Yes these demos use 'localhost' in the request. I get the same result using the actual domain name from various machines on various networks though.
Two questions then:
Could this be IIS not applying the compression due to the extra header? and if so what can I do about it?
How can I tell if the proxy is decompressing the content before returning it?
Bonus question 3 - What can I do to investigate this problem further?
I am aware of question 332049, but that has the header in the response, not the request.
I stumbled across your question while researching this myself. I uncovered an article on MSDN and the short answer is that the Via header is used for proxies and proxies typically mess up compression. You either have the option of removing the header or you can change the setting in the IIS metabase (HcNoCompressionForProxies="FALSE"). I had success with both options.

Resources