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 :-)
Related
I am accessing OneDrive from a C++ program using WinHttp* functions. What absolutely baffles me is REST API download command. I am downloading a small test picture with
GET /v1.0/drive/items/FF306293D40F9529!158/content
When I do this in the console, I get a response exactly as described in the docs, that is, a 302 redirect to the actual content. However when I send the same request with WinHttpSendRequest, I receive the actual file contents instead of a redirection:
HTTP/1.1 200 OK
Cache-Control: public
Date: Wed, 06 Jan 2016 10:22:36 GMT
Content-Length: 161796
Content-Type: image/jpeg
Content-Location: https://public-bn1306.files.1drv.com/blahblahbla
Expires: Tue, 05 Apr 2016 10:22:36 GMT
Last-Modified: Wed, 06 Jan 2016 10:22:35 GMT
Accept-Ranges: bytes
ETag: aRkYzMDYyOTNENDBGOTUyOSExNTguMw
P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
Server: Microsoft-IIS/8.5
X-MSNSERVER: BN1306____PAP099
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-SqlDataOrigin: S
CTag: aYzpGRjMwNjI5M0Q0MEY5NTI5ITE1OC4yNTc
X-PreAuthInfo: rv;poba;
Content-Disposition: attachment; filename="Test.jpg"
X-Content-Type-Options: nosniff
X-StreamOrigin: X
X-AsmVersion: UNKNOWN; 19.33.0.0
X-MSEdge-Ref: Ref A: 44F40B6FB83547EFBC895911207BDB42 Ref B: 96336B0FC1B608598B549A1CB70C8C59 Ref C: Wed Jan 06 02:22:36 2016 PST
First I thought that maybe it was because the file was small, but trying to download a 250Mb large binary file changed nothing.
I don't complain actually, this would make the program a bit simpler, but I certainly would like to know why the same request works differently with WinHttp*. I suppose I do something wrong, but what??? (Banging my head against my desk.)
There are http libraries that will follow redirects automatically. You send a request, the library receives 302, and decides on its own to go to the redirect location, which then returns a 200.
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.
I'm experimenting a very strange issue: using apache-2.2.25 on an Arch Linux server I get a truncated HTTP header in response, but only under windows machines.
I left untouched the httpd.conf file and I have created a file /srv/http/index.html with inside Hello.
With a web browser on a Linux machine I get correctly visualized the hello page, but under Windows I get
.1 200 OK Date: Fri, 15 Nov 2013 08:44:28 GMT Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.1e DAV/2 Last-Modified: Fri, 15 Nov 2013 08:15:09 GMT ETag: "27c-a-4eb32cbf8b950" Accept-Ranges: bytes Content-Length: 10 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Hello
It seems that the http header is truncated for the first characters (HTTP/1).
Have you got any advices?
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/xml; charset=utf-8
Expires: Tue, 06 Dec 2011 21:42:35 GMT
ETag: 28
Vary: *
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Tue, 06 Dec 2011 21:42:24 GMT
Content-Length: 258
I am building the expiration date myself and setting it, yet it still won't cache. I am using SqlDependency with this, but what I want for it to do is hold it in cache for say...30 minutes, then after 30 sql cache comes into play.
First thing that I notice is "Cache-Control: private". As long is it private it won't be cached by proxies and I'm not sure all the browsers will cache it.
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.