Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for more HTTP cache controls #33134

Merged
merged 1 commit into from Jun 19, 2018

Conversation

Projects
None yet
3 participants
@dasch
Copy link
Contributor

dasch commented Jun 13, 2018

Adds support for the stale-while-revalidate and stale-if-error extensions to the Cache-Control response header.

From https://tools.ietf.org/html/rfc5861:

The stale-if-error HTTP Cache-Control extension allows a cache to
return a stale response when an error -- e.g., a 500 Internal Server
Error, a network segment, or DNS failure -- is encountered, rather
than returning a "hard" error. This improves availability.

The stale-while-revalidate HTTP Cache-Control extension allows a
cache to immediately return a stale response while it revalidates it
in the background, thereby hiding latency (both in the network and on
the server) from clients.

These are useful, fully standardized parts of the HTTP protocol with widespread support among CDN vendors. Supporting them will make it easier to utilize reverse proxies and CDNs from Rails without resorting to hacks.

The expires_in method doesn't seem to document the various options – is there a specific place I should document this?

Add support for more HTTP cache controls
From <https://tools.ietf.org/html/rfc5861>:

> The stale-if-error HTTP Cache-Control extension allows a cache to
> return a stale response when an error -- e.g., a 500 Internal Server
> Error, a network segment, or DNS failure -- is encountered, rather
> than returning a "hard" error.  This improves availability.
>
> The stale-while-revalidate HTTP Cache-Control extension allows a
> cache to immediately return a stale response while it revalidates it
> in the background, thereby hiding latency (both in the network and on
> the server) from clients.

These are useful, fully standardized parts of the HTTP protocol with
widespread support among CDN vendors. Supporting them will make it
easier to utilize reverse proxies and CDNs from Rails.
@dasch

This comment has been minimized.

Copy link
Contributor Author

dasch commented Jun 18, 2018

@eileencodes eileencodes merged commit 2be5ef6 into rails:master Jun 19, 2018

2 checks passed

codeclimate All good!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@eileencodes

This comment has been minimized.

Copy link
Member

eileencodes commented Jun 19, 2018

Thanks!

@dasch

This comment has been minimized.

Copy link
Contributor Author

dasch commented Jun 19, 2018

❤️!

@dasch dasch deleted the dasch:dasch/extra-cache-controls branch Jun 19, 2018

@mikhailov

This comment has been minimized.

Copy link
Contributor

mikhailov commented Sep 3, 2018

this PR is extremely useful to cover use cases like one described by Cloudflare:

Cache an asset and serve the asset while it is being revalidated
Cache-Control: max-age=600, stale-while-revalidate=30

Indicates that it is fresh for 600 seconds, and it may continue to be served stale for up to an additional 30 seconds to parallel requests for the same resource while the initial synchronous revalidation is attempted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.