Security News
Oracle Drags Its Feet in the JavaScript Trademark Dispute
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
Rack::Cache is suitable as a quick drop-in component to enable HTTP caching for
Rack-based applications that produce freshness (expires
, cache-control
)
and/or validation (last-modified
, etag
) information:
if-modified-since
/ if-none-match
)vary
supportcache-control
public
, private
, max-age
, s-maxage
, must-revalidate
,
and proxy-revalidate
.For more information about Rack::Cache features and usage, see:
https://rack.github.io/rack-cache/
Rack::Cache is not overly optimized for performance. The main goal of the project is to provide a portable, easy-to-configure, and standards-based caching solution for small to medium sized deployments. More sophisticated / high-performance caching systems (e.g., Varnish, Squid, httpd/mod-cache) may be more appropriate for large deployments with significant throughput requirements.
gem install rack-cache
Rack::Cache
is implemented as a piece of Rack middleware and can be used with
any Rack-based application. If your application includes a rackup (.ru
) file
or uses Rack::Builder to construct the application pipeline, simply require
and use as follows:
require 'rack/cache'
use Rack::Cache,
metastore: 'file:/var/cache/rack/meta',
entitystore: 'file:/var/cache/rack/body',
verbose: true
run app
Assuming you've designed your backend application to take advantage of HTTP's caching features, no further code or configuration is required for basic caching.
# config/application.rb
config.action_dispatch.rack_cache = true
# or
config.action_dispatch.rack_cache = {
verbose: true,
metastore: 'file:/var/cache/rack/meta',
entitystore: 'file:/var/cache/rack/body'
}
You should now see Rack::Cache
listed in the middleware pipeline:
rake middleware
Dalli is a high performance memcached client for Ruby. More information at: https://github.com/mperham/dalli
require 'dalli'
require 'rack/cache'
use Rack::Cache,
verbose: true,
metastore: "memcached://localhost:11211/meta",
entitystore: "memcached://localhost:11211/body"
run app
Does not persist response bodies (no disk/memory used).
Responses from the cache will have an empty body.
Clients must ignore these empty cached response (check for x-rack-cache
response header).
Atm cannot handle streamed responses, patch needed.
require 'rack/cache'
use Rack::Cache,
verbose: true,
metastore: <any backend>
entitystore: "noop:/"
run app
It's fairly common to include tracking parameters which don't affect the content
of the page. Since Rack::Cache uses the full URL as part of the cache key, this
can cause unneeded churn in your cache. If you're using the default key class
Rack::Cache::Key
, you can configure a proc to ignore certain keys/values like
so:
Rack::Cache::Key.query_string_ignore = proc { |k, v| k =~ /^(trk|utm)_/ }
FAQs
Unknown package
We found that rack-cache demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
Security News
The Linux Foundation is warning open source developers that compliance with global sanctions is mandatory, highlighting legal risks and restrictions on contributions.
Security News
Maven Central now validates Sigstore signatures, making it easier for developers to verify the provenance of Java packages.