| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since #30367, if `no-cache` includes Cache-Control headers, special keys
like `public`, `must-revalidate` are ignored.
But in my understanding, `public` still need in case of want to cache
authenticated pages.
The authenticated pages to be cacheable, but still authenticated for
every user, need to specify the `Cache-Control: public, no-cache`.
For keys other than `public`, I did not know the case where it was
necessary to use it in combination with `no-cache`, so I fixed that can
be used only for `public`.
Ref: https://www.mnot.net/cache_docs/#CACHE-CONTROL
Fixes #34780.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rails 6.0 will support Ruby 2.4.1 or higher
`# frozen_string_literal: true` magic comment is enough to make string object frozen.
This magic comment is enabled by `Style/FrozenStringLiteralComment` cop.
* Exclude these files not to auto correct false positive `Regexp#freeze`
- 'actionpack/lib/action_dispatch/journey/router/utils.rb'
- 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb'
It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333
Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed.
* Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required
- 'actionpack/test/controller/test_case_test.rb'
- 'activemodel/test/cases/type/string_test.rb'
- 'activesupport/lib/active_support/core_ext/string/strip.rb'
- 'activesupport/test/core_ext/string_ext_test.rb'
- 'railties/test/generators/actions_test.rb'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
implementation
and defaults to `Digest::MD5`.
Replaced calls to `::Digest::MD5.hexdigest` with calls to `ActiveSupport::Digest.hexdigest`.
|
|\
| |
| | |
Normalize/process Cache-Control headers consistently
|
| |
| |
| |
| |
| |
| | |
The prior logic explictly set `Cache-Control` to `nil`. But, we would only
reach that logic if the header was not set to begin with. So, rather than give
it any value at all, just leave it alone.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The prior logic was trying to do too many things at once. For all responses,
we want to perform two distinct steps:
* Merge/normalize the `Cache-Control` values found in HTTP headers and those
found in the `@cache_control` hash.
* Conditionally set a default `Cache-Control` header value when we have an ETag
This change separates these concerns since the merge/normalize step should
occur for all responses, but the second should only occur when we have already
set an ETag/last modified value. Normally ETag middleware will set a default
`Cache-Control`, but only if an existing ETag is not already set. So, in the
cases where an ETag is set, we need to set the default `Cache-Control` value
ourselves.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the existing logic, the `Cache-Control` header may or may not get
normalized by additional logic depending on whether `response.cache_conrol`
has been modified. This leads to inconsistent behavior, since sometimes
`Cache-Control` can contain whatever a user sets and sometimes it gets
normalized, based on the logic inside of `set_conditional_cache_control!`. It
seems like this normalization process should happen regardless to ensure
consistent behavior.
|
|/ |
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Introduce `Response#strong_etag=` and `#weak_etag=` and analogous options
for `fresh_when` and `stale?`. `Response#etag=` sets a weak ETag.
Strong ETags are desirable when you're serving byte-for-byte identical
responses that support Range requests, like PDFs or videos (typically
done by reproxying the response from a backend storage service).
Also desirable when fronted by some CDNs that support strong ETags
only, like Akamai.
* No longer strips quotes (`"`) from ETag values before comparing them.
Quotes are significant, part of the ETag. A quoted ETag and an unquoted
one are not the same entity.
* Support `If-None-Match: *`. Rarely useful for GET requests; meant
to provide some optimistic concurrency control for PUT requests.
|
|
|
|
|
|
| |
Fixes some parts of #23148.
[ci skip]
|
|
|
|
| |
ActionDispatch::Http::Cache::Response#etag= such that etags set in fresh_when and stale? are weak. For #17556.
|
|
|
|
|
| |
This shouldn't generally come up: under a standard flow, we don't start
sending until after the commit. But application code always finds a way.
|
|
|
|
|
| |
Use the methods rack provides so we don't have to worry about the exact
header key.
|
|
|
|
|
| |
Rack implements the Etag header manipulation methods, so we can use
those instead of ours.
|
|
|
|
|
|
|
| |
* Introduce `ActionDispatch::Http::Headers#add` to add a value to
a multivalued header.
* Move `Response#add_header` upstream: https://github.com/rack/rack/pull/957
* Match upstream `Response#have_header?` -> `#has_header?` name change.
|
| |
|
|
|
|
|
| |
eventually we'll remove this instance variable, but this is the first
step
|
|
|
|
|
| |
we're storing the value in the headers hash, so lets just store the
value in one place.
|
|
|
|
|
| |
Modules should be using the API that the abstract modules use so that we
can move these modules between implementations
|
|
|
|
| |
We don't want to directly access the env hash
|
|
|
|
|
|
| |
People should be free to mutate the header object, but not to set a new
header object. That header object may be specific to the webserver, and
we need to hide it's internals.
|
|
|
|
| |
headers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Slightly improves performance, for example, a simple benchmark:
```ruby
require 'benchmark/ips'
require 'set'
SPECIAL_KEYS = %w[extras no-cache max-age public must-revalidate]
SPECIAL_KEYS_SET = Set.new(SPECIAL_KEYS)
directive = 'must-revalidate'
Benchmark.ips do |x|
x.report('array') { SPECIAL_KEYS.include?(directive) }
x.report('set') { SPECIAL_KEYS_SET.include?(directive) }
end
```
Output:
```
-------------------------------------
array 67926 i/100ms
set 74054 i/100ms
-------------------------------------
array 2318423.4 (±2.8%) i/s - 11615346 in 5.014899s
set 3387981.8 (±4.7%) i/s - 16958366 in 5.019355s
```
|
| |
|
|
|
|
| |
This fix the build http://travis-ci.org/#!/rails/rails/builds/2459981
|
| |
|
|
|
|
|
|
|
|
| |
This is a rebased version of #2520.
Conflicts:
actionpack/test/dispatch/request_test.rb
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several aspects to this commit, that don't well fit into broken down
commits, so they are detailed here:
* When a user uses response.headers['Cache-Control'] = some_value, then the
documented convention in ConditionalGet is not adhered to, in this case,
response.cache_control is ignored due to `return if
self[CACHE_CONTROL].present?`
* When a middleware sets cache-control headers that would clobber, they're
converted to symbols directly, without underscores. This would lead to bugs.
* Items that would live in :extras if set through expires_in, are placed
directly in the @cache_control hash, and not respected in many cases
(somewhat adhering to the aforementioned documentation).
* Although quite useless, any directive named 'extras' would be ignored.
The general convention applied is that expires_* take precedence, but no longer
overwrite everything and expires_* are ALWAYS applied, even if the header is
set.
I am still unhappy about the contents of this commit, and the code in general.
Ideally it should be refactored to no longer use :extras. I'd likely recommend
expanding @cache_control into a class, and giving it the power to handle the
merge in a more efficient fashion. Such a commit would be a larger change that
could have additional semantic changes for other libraries unless they utilize
expires_in in very standard ways.
|
|\
| |
| | |
Ensure Date header on expires_in
|
| | |
|
|/ |
|
|
|
|
| |
deprecated and is going to be removed in future releases.
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Response object that does up-front parsing of the headers to populate things like @etag
|
|
|