I'm using Apache 2.2.16.
I've got the following HTML file in my htdocs folder:
<html>
<link media="screen" type="text/css" href="/css/test.css" rel="stylesheet" />
<body>XXXX</body>
</html>
I'm trying to make the CSS file cache in my browser so that it does not make another request for it, apart from on the first ever page load.
However, every time I press refresh, I can see that the CSS file is loaded again from the server. I see 200 response codes for the file in my server logs.
I've got the following in my httpd.conf file:
<LocationMatch "\.(css)$">
Header set Cache-Control "max-age=2592000"
Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"
Header unset Last-Modified
Header set Content-Type text/css
Header unset ETag
</LocationMatch>
Here are my response headers, as reported by Firebug:
Date Mon, 29 Nov 2010 10:48:49 GMT
Server Apache/2.2.16 (Win32)
Accept-Ranges bytes
Content-Length 18107
Cache-Control max-age=2592000
Expires Thu, 15 Apr 2020 20:00:00 GMT
Content-Type text/css
Keep-Alive timeout=5, max=97
Connection Keep-Alive
I've read a few articles about setting the caching headers, but I just can't see to get it working.
Any advice greatly appreciated.
I've seen similar problems with configurations that manually set expires & cache-control. Just letting mod_expires do that "heavy lifting" might already solve these issues?
Related
I have a Digital Ocean Ubuntu 16.04 server running Laravel.
I have a couple crons running every minute in the scheduler that trigger the Quickbooks API library. Everytime it runs it logs a text file similar to below. It creates a request and response txt file:
RESPONSE URI FOR SEQUENCE ID 04745
==================================
https://quickbooks.api.intuit.com/v3/company/123456/query?minorversion=54
RESPONSE HEADERS
================
date: Tue, 15 Dec 2020 18:15:51 GMT
content-type: application/xml;charset=UTF-8
content-length: 1193
connection: close
server: nginx
strict-transport-security: max-age=15552000
intuit_tid: 1-5fd8fd57-123456
x-spanid: d59bb673-e981-4d61-9bdf-123456
x-amzn-trace-id: Root=1-5fd8fd57-123456
set-cookie: JSESSIONID=123456.c21-pprdc21uw2apv019661-stack-b; Domain=qbo.intuit.com; Path=/; Secure; Ht$
qbo-version: 1949.239
service-time: total=8, db=3
expires: 0
cache-control: max-age=0, no-cache, no-store, must-revalidate, private
vary: Accept-Encoding
x-xss-protection: 1; mode=block
RESPONSE BODY
=============
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<IntuitResponse xmlns="http://schema.intuit.com/finance/v3" time="2020-12-15T10:15:51.199-08:00">
<QueryResponse startPosition="1" maxResults="1">
<Vendor domain="QBO" sparse="false">
<Id>6213</Id>.....
I don't need these logs created. How can I stop these from being created? I am not sure if they are being created from Ubuntu, Laravel or the Quickbooks API.
The bandaid is that I have a cron to remove these files from a shell script but I am trying to stop them from being generated in the first place. Thanks
It looks like a response from QuickBooks API. You can check here or here to find out how to disable or modify response log.
I'm using Nginx + uWsgi + web2py framework, and I want to make Nginx to cache the HTML responses generated by web2py.
The HTML headers generated by web2py are these:
Cache-Control:max-age=300, s-maxage=300, public
Connection:keep-alive
Content-Length:147
Content-Type:text/html; charset=utf-8
Date:Mon, 27 Mar 2017 16:27:54 GMT
Expires:lun, 27 mar 2017 16:32:54 GMT
Server:Rocket 1.2.6 Python/2.7.6
X-Powered-By:web2py
Those are the ones served directly with the web2py embedded server.
The same request served with nginx and uwsgi (without any cache configuration) produces these headers:
Cache-Control:max-age=300, s-maxage=300, public
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Mon, 27 Mar 2017 16:31:09 GMT
Expires:lun, 27 mar 2017 16:36:09 GMT
Server:nginx
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:web2py
Now, I want to implement uwsgi_cache for nginx configuration, and I'm trying like this:
uwsgi_cache_path /tmp/nginx_cache/ levels=1:2 keys_zone=mycache:10m max_size=10g inactive=10m use_temp_path=off;
server {
listen 80;
server_name myapp.com;
root /home/user/myapp;
location / {
uwsgi_cache mycache;
uwsgi_cache_valid 200 15m;
uwsgi_cache_key $request_uri;
add_header X-uWSGI-Cache $upstream_cache_status;
expires 1h;
uwsgi_pass unix:///tmp/myapp.socket;
include uwsgi_params;
uwsgi_param UWSGI_SCHEME $scheme;
uwsgi_param SERVER_SOFTWARE nginx/$nginx_version;
}
}
However, every time I hit an URL, I get a MISS in the response headers, indicating that nginx didn't serve the request from cache:
Cache-Control:max-age=3600
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Mon, 27 Mar 2017 16:37:29 GMT
Expires:Mon, 27 Mar 2017 22:37:29 GMT
Server:nginx
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:web2py
X-uWSGI-Cache:MISS
The nginx process is running as "www-data" user/group. I've checked the permissions of the folder /tmp/nginx_cache/ and they are ok: the user has permissions to read and write the folder. Also, inside the /tmp/nginx_cache/ a "temp" folder is created by nginx, but no cache files are written there.
I've tried also adding proxy_ignore_headers to location block in order to instruct nginx to ignore some headers like Set-Cookie and Cache-Control, like this:
location / {
uwsgi_cache mycache;
uwsgi_cache_valid 200 15m;
uwsgi_cache_key $scheme$proxy_host$uri$is_args$args;
add_header X-uWSGI-Cache $upstream_cache_status;
proxy_ignore_headers X-Accel-Expires Expires Cache-Control Set-Cookie Vary;
uwsgi_pass unix:///tmp/myapp.socket;
include uwsgi_params;
uwsgi_param UWSGI_SCHEME $scheme;
uwsgi_param SERVER_SOFTWARE nginx/$nginx_version;
}
However, this makes no difference: the first request isn't cached, and all the subsequent requests are a MISS, that is, they aren't served from cache.
I've found this similar post, where the person who answers points out that it could be a problem of the response headers generated by (in this case) web2py:
https://serverfault.com/questions/690164/why-is-this-nginx-setup-not-caching-responses
Why nginx isn't caching the responses?
I've found the cause of the issue: I was mixing uwsgi_cache_* directives with proxy_cache_* directives, and they belong to different Nginx modules. I just needed to replace proxy_ignore_headers with uwsgi_ignore_headers.
Notice that proxy_cache module is different than uwsgi_cache, they have very similar directives, but they are two different modules.
I've got nginx sitting between ELBs. I've got a couple application pools behind an ELB that nginx passes traffic back to and I want to cache static content. My problem is nginx doesn't appear to be caching any responses. This is the cache configuration:
proxy_cache_path /usr/share/nginx/cache/app levels=1:2 keys_zone=cms-cache:8m max_size=1000m inactive=600m;
proxy_temp_path /usr/share/nginx/cache/;
location / {
proxy_pass http://cms-pool;
proxy_cache cms-cache;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
}
After some reading I found there might be some headers causing the issue but after hiding the obvious ones I had no luck and ended up breaking the application since I was hiding all the backend cookies. These are the headers I tried removing:
proxy_ignore_headers Cache-Control Expires Set-Cookie;
proxy_hide_header Cache-Control;
proxy_hide_header Set-Cookie;
I'm at a loss right now as to why requests are not being cached, here's an output from curl of the headers that came through with the above header configuration (the cookies and such were set from nginx/elb in front of nginx):
Accept-Ranges: bytes
Connection: keep-alive
Content-length: 6821
Content-Type: text/html
Date: Sun, 16 Nov 2014 19:25:41 GMT
ETag: W/"6821-1415964130000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT
HTTP/1.1 200 OK
Last-Modified: Fri, 14 Nov 2014 11:22:10 GMT
Pragma: no-cache
Server: nginx/1.7.6
Set-Cookie: AWSELB=4BB7AB49169E74EC05060FB9839BD30C2CB1D0E43D90837DC593EB2BA783FB372E90B6F6F575D13C6567102032557C76E00B1F5DB0B520CF929C3B81327C1D259A9EA5C73771C4EA3DB6390EB40484EDF56491135B;PATH=/
Set-Cookie: frontend=CgAAi1Ro+jUDNkZYAwMFAg==; path=/
Update I found that the above wasn't entirely accurate as there's a 302 that directs a user to login which hits another backend that doesn't have static resources, as such the headers above are coming from the login backend. I adjusted the URI to point to just the images but no caching is occurring. I'm using the following location block:
location /app/images {
proxy_pass http://cms-pool/app/images;
proxy_cache cms-cache;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
proxy_ignore_headers Cache-Control Expires Set-Cookie;
proxy_hide_header Cache-Control;
proxy_hide_header Set-Cookie;
}
These are the headers which are coming through now:
Accept-Ranges: bytes
Connection: keep-alive
Content-length: 12700
Content-Type: image/png
Date: Mon, 17 Nov 2014 09:25:38 GMT
ETag: "0cd80ce9afecf1:0"
HTTP/1.1 200 OK
Last-Modified: Wed, 12 Nov 2014 17:05:06 GMT
Server: nginx/1.7.6
Set-Cookie: AWSELB=4BB7AB49169E74EC05060FB9839BD30C2CB1D0E43D638163025E92245C6C6E40197CA48C5B22F3E8FDA53365109BC1C16C808322881855C100D4AC54E5C0EC6CDE91B96151F66369C7B697B04D2C08439274033D81;PATH=/
Set-Cookie: tscl-frontend=CgAK1FRpvxI4b0bQAwMEAg==; path=/
X-Powered-By: ASP.NET
This is caused by a wobbly implementation of HTTP caching headers in what's behind ELB.
Per RFC 2616 (HTTP 1.1) :
Pragma directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives might be applicable to all recipients along the
request/response chain.
HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
sent "Cache-Control: no-cache". No new Pragma directives will be
defined in HTTP.
Note: because the meaning of "Pragma: no-cache as a response
header field is not actually specified, it does not provide a
reliable replacement for "Cache-Control: no-cache" in a response
The Pragma: no-cache header doesn't mean anything in an HTTP reply because it's behaviour is unspecified by RFCs.
But as nginx acts as a (reverse) proxy in your case, it will honor the header as if it was Cache-Control: no-cache header to maintain compatibility with HTTP 1.0 protocol's Pragma header defined in RFC 1945.
It will also pass it through client's response headers as it doesn't have to suppose anything about the actual meaning of it.
So either correct this bad implementation or append Pragma header to proxy_ignore_headers and proxy_hide_header directives.
I've been working on a development box deploying an Nginx, Magento, HHVM model. The site loads nicely and I don't get any real clear errors that I can see. However, a good number of my images are not loading properly. All I get are the image dimensions. The version of HHVM I'm using is:
HipHop VM 3.3.0-dev (rel)
Compiler: heads/master-0-g39d07abf36f7cad883d6be2a384a77c0c8aac040
Repo schema: 248cb6ce2d336c890fb26fd16690bf1b53b46994
Extension API: 20140829
The version of Nginx is:
nginx version: nginx/1.7.4
Some images load, and others don't. We're using timthumb for images, and I do see one error:
\nWarning: Is a directory in /home/user/shared/timthumb/index.php on line 90
If I run a curl from the command-line, I get the following result for an image, which means it's being seen as far as I can tell:
HTTP/1.1 200 OK
Content-Type: image/gif
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: HHVM/3.3.0-dev
CF-Cache-Status: HIT
CF-RAY: 16513733df33085c-IAD
Server: cloudflare-nginx
Date: Fri, 05 Sep 2014 08:56:47 GMT
Expires: Sun, 05 Oct 2014 08:56:47 GMT
Cache-Control: public, max-age=2592000
Set-Cookie: __cfduid=d6c188df6595a443200995301f0b707981409907407975; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.placehold.it; HttpOnly
Last-Modified: Fri, 19 Nov 2010 07:00:00 GMT
Cache-Control: max-age=31536000, public, must-revalidate, proxy-revalidate
I have a separate test server with the same content/database running NGINX/PHP-FPM, and the only variable I can see that's different in the curl is that when I run the curl against the dev server running php-fpm, the result is Content-Type: image/jpeg. When I run it against HHVM I get Content-Type: image/gif.
I would think this is related to rewrite rules, but I'm not sure. I also just discovered this error here as well in exception.log:
2014-09-05T12:04:06+00:00 ERR (3): Warning: open(tcp://127.0.0.1:11211?persistent=1&weight=2&timeout=10&retry_interval=10/sess_dd885307c2ba602e5faa7020c9c7c038, O_RDWR) failed: No such file or directory (2) in on line 0
Any advice would be greatly appreciated.
I'm trying cache static images in IIS. It's partially working - the images cache between requests when clicking through the site. But if I go to a different site (like google) then come back, I can see the images reloading again.
I'm not doing hard refresh, just pasting the url in the location bar and pressing [ENTER].
Here's my caching settings in the web.config:
<system.webServer>
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="5.00:00:00" />
</staticContent>
...
When I run curl --head ... on my image, here's what I get:
HTTP/1.1 200 OK
Cache-Control: max-age=432000
Content-Length: 10199
Content-Type: image/png
Last-Modified: Mon, 21 Jan 2013 21:58:43 GMT
Accept-Ranges: bytes
ETag: "fbaa7c7a22f8cd1:0"
Server: Microsoft-IIS/7.0
Set-Cookie: SessionId=14ab46aa-7633-412f-95c3-a3ce0667eb25; expires=Tue, 18-Apr-2113 16:17:54 GMT; path=/
X-Powered-By: ASP.NET
Date: Thu, 18 Apr 2013 16:17:54 GMT
I would expect the browser to read the cache until it expired. Any ideas why it's not using the cache?