1. Conceptually revert #20276
The feature was implemented for the `responders` gem. In the end,
they did not need that feature, and have found a better fix (see
plataformatec/responders#131).
`ImplicitRender` is the place where Rails specifies our default
policies for the case where the user did not explicitly tell us
what to render, essentially describing a set of heuristics. If
the gem (or the user) knows exactly what they want, they could
just perform the correct `render` to avoid falling through to
here, as `responders` did (the user called `respond_with`).
Reverting the patch allows us to avoid exploding the complexity
and defining “the fallback for a fallback” policies.
2. `respond_to` and templates are considered exhaustive enumerations
If the user specified a list of formats/variants in a `respond_to`
block, anything that is not explicitly included should result
in an `UnknownFormat` error (which is then caught upstream to
mean “406 Not Acceptable” by default). This is already how it
works before this commit.
Same goes for templates – if the user defined a set of templates
(usually in the file system), that set is now considered exhaustive,
which means that “missing” templates are considered `UnknownFormat`
errors (406).
3. To keep API endpoints simple, the implicit render behavior for
actions with no templates defined at all (regardless of formats,
locales, variants, etc) are defaulted to “204 No Content”. This
is a strictly narrower version of the feature landed in #19036 and
#19377.
4. To avoid confusion when interacting in the browser, these actions
will raise an `UnknownFormat` error for “interactive” requests
instead. (The precise definition of “interactive” requests might
change – the spirit here is to give helpful messages and avoid
confusions.)
Closes#20666, #23062, #23077, #23564
[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]
Having collection caching that wraps templates and automatically tries
to infer if they are cachable proved to be too much of a hassle.
We'd rather have it be something you explicitly turn on.
This removes much of the code and docs to explain the previous automatic
behavior.
This change also removes scoped cache keys and passing cache_options.
The `cache` helper methods should pass any extra options
to the cache store. For example :expires_in would be a
valid option if memcache was the cache store. The change
in commit da16745 broke the ability to pass any options
other than :skip_digest and :virtual_path. This PR
restores that functionality and adds a test for it.
Set `config.static_index` to serve a static directory index file not
named `index`. For example, to serve `main.html` instead of `index.html`
for directory requests, set `config.static_index` to `"main"`.
Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.
The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.
So with a notifications/_notification.html.erb template like:
```ruby
<% cache notification %>
<%# ... %>
<% end %>
```
A collection would be able to use `multi_read` if rendered like:
```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```
Dir.glob can be a security concern. The original use was to provide logic of fallback files. Example a request to `/` should render the file from `/public/index.html`. We can replace the dir glob with the specific logic it represents. The glob {,index,index.html} will look for the current path, then in the directory of the path with index file and then in the directory of the path with index.html. This PR replaces the glob logic by manually checking each potential match. Best case scenario this results in one less file API request, worst case, this has one more file API request.
Related to #16464
Update: added a test for when a file of a given name (`public/bar.html` and a directory `public/bar` both exist in the same root directory. Changed logic to accommodate this scenario.
- don't mutate PATH_INFO in env, test
- test fallback content type matches Rack::File
- change assertion style
- make HTTP_ACCEPT_ENCODING comparison case insensitive
- return gzip path from method instead of true/false so we don't have to assume later
- don't allocate un-needed hash.
Original comments:
https://github.com/rails/rails/commit/
cfaaacd9763642e91761de54c90669a88d772e5a#commitcomment-7468728
cc @jeremy
If someone is using ActionDispatch::Static to serve assets and makes it past the `match?` then the file exists on disk and it will be served. This PR adds in logic that checks to see if the file being served is already compressed (via gzip) and on disk, if it is it will be served as long as the client can handle gzip encoding. If not, then a non gzip file will be served.
This additional logic slows down an individual asset request but should speed up the consumer experience as compressed files are served and production applications should be delivered with a CDN. This PR allows a CDN to cache a gzip file by setting the `Vary` header appropriately. In net this should speed up a production application that are using Rails as an origin for a CDN. Non-asset request speed is not affected in this PR.
Related to: #14242#14243 14293
Variants passed to LookupContext#find() seem to be ignored, so
I've used the setter instead: `finder.variants = [ variant ]`.
I've also added some more test cases for variants. Hopefully this
time passing tests will mean it actually works.
In #5337 we forced the path encoding to ASCII-8BIT to prevent static
file handling from blowing up before an application has had chance to
deal with possibly invalid urls. However this has a negative side
effect of making it an incompatible encoding if the application's
public path has UTF-8 characters in it.
To work around the problem we check to see if the path has a valid
encoding once it has been unescaped. If it is not valid then we can
return early since it will not match any file anyway.
Fixes#13518
Like `format.any`, you can do the same with variants.
It works for both inline:
respond_to do |format|
format.html.any { render text: "any" }
format.html.phone { render text: "phone" }
end
and block syntax:
respond_to do |format|
format.html do |variant|
variant.any(:tablet, :phablet){ render text: "any" }
variant.phone { render text: "phone" }
end
end
In most cases, when setting variant specific code, you're not sharing any code
within format.
Inline syntax can vastly simplify defining variants in those situations:
respond_to do |format|
format.js { render "trash" }
format.html do |variant|
variant.phone { redirect_to progress_path }
variant.none { render "trash" }
end
end
Becomes:
respond_to do |format|
format.js { render "trash" }
format.html.phone { redirect_to progress_path }
format.html.none { render "trash" }
end
By default, variants in the templates will be picked up if a variant is set
and there's a match. The format will be:
app/views/projects/show.html.erb
app/views/projects/show.html+tablet.erb
app/views/projects/show.html+phone.erb
If request.variant = :tablet is set, we'll automatically be rendering the
html+tablet template.
In the controller, we can also tailer to the variants with this syntax:
class ProjectsController < ActionController::Base
def show
respond_to do |format|
format.html do |html|
@stars = @project.stars
html.tablet { @notifications = @project.notifications }
html.phone { @chat_heads = @project.chat_heads }
end
format.js
format.atom
end
end
end
The variant itself is nil by default, but can be set in before filters, like
so:
class ApplicationController < ActionController::Base
before_action do
if request.user_agent =~ /iPad/
request.variant = :tablet
end
end
end
This is modeled loosely on custom mime types, but it's specifically not
intended to be used together. If you're going to make a custom mime type,
you don't need a variant. Variants are for variations on a single mime
types.
This PR fixes#13064 regression bug introduced by the #8085
Now in _process_format when the format is a Mime::NullType nothing is written in self.content_type.
In this way the method Response#assign_default_content_type_and_charset can
write the the default mime_type.
This fixes an issue where the respond_with worked directly with the given
options hash, so that if a user relied on it after calling respond_with,
the hash wouldn't be the same.
Fixes#12029
HelperyTestHelper was introduced in 66ef922 by @josevalim
to pair with HelperyTestController. This test controller was
later removed in e10a253 by @strzalek, leaving HelperyTestHelper unused
When helper try to require missing file rails will throw exception about
missing helper.
# app/helpers/my_helper.rb
require 'missing'
module MyHelper
end
And when we try do load helper
class ApplicationController
helper :my
end
Rails will throw exception. This is wrong because there is a helper
file.
Missing helper file helpers/my_helper.rb
Now when helper try to require non-existed file rails will throw proper
exception.
No such file to load -- missing