| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
The /rails/info routes were inaccessible in apps with a catch-all
globbing route, as they were being appended after the globbing route and
would never be matched.
See also ccc3ddb7762bae0df7e2f8d643b19b6a4769d5be.
|
|
|
|
| |
http://edgeguides.rubyonrails.org/api_documentation_guidelines.html#english
|
|\
| |
| |
| |
| | |
prathamesh-sonpatki/add-config-to-deprecation-warning
Add `config` to the deprecation warnings of deprecated config options
|
| | |
|
|/
|
|
|
|
| |
With the exception of what is loaded in active_support/rails,
each file is responsible for its own dependencies. You cannot
rely on runtime order of execution.
|
|
|
|
| |
Also, make sure to call the +complete+ hooks if +run+ fails.
|
|\
| |
| | |
Added 'config.' to deprecation warning
|
| |
| |
| |
| | |
Misc:
`config.public_file_server.enabled = true` instead `public_file_server.enabled = true`
|
| |
| |
| |
| |
| |
| | |
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to provide a way for Action Cable, Sprockets, and possibly
other Rack applications to mark themselves as internal, and to exclude
themselves from the routing inspector, and thus `rails routes` / `rake
routes`.
I think this is the only way to have mounted Rack apps be marked as
internal, within AD/Journey. Another option would be to create an array
of regexes for internal apps, and then to iterate over that everytime a
request comes through. Also, I only had the first `add_route` method set
`internal`'s default to false, to avoid littering it all over the
codebase.
|
|
|
|
|
|
| |
We mostly care about `reload_classes_only_on_change=true`, because
that's the default... and there, we definitely need to wait for the lock
when necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, the sole presence of the Listen constant
enabled the evented file watcher (unless listen resorted to
the polling backend).
This way, applications may depend on listen for other stuff
independently of this feature. Also, allows teams with mixed
setups to decide at boot time whether the evented watcher
should be enabled for each particular instance.
|
| |
|
| |
|
| |
|
|
|
|
| |
behavior
|
| |
|
|
|
|
|
| |
Railsties tests are broken with this new update checker so we will use
the old one until we have the tests fixed.
|
|
|
|
| |
Also call it `public_server.index_name` so it'll make more sense.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the implementation of the file update checker written
by Puneet Agarwal for GSoC 2015 (except for the tiny version
of the listen gem, which was 3.0.2 in the original patch).
Puneet's branch became too out of sync with upstream. This is
the final work in one single clean commit.
Credit goes in the first line using a convention understood
by the contrib app.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Fix the message by wrapping the value in missing quotes and adding
the missing backtick at the end. Finally, :lipstick: by adding a space
inside the curly braces.
Before:
`config.public_file_server.headers = {'Cache-Control' => public,
max-age=31536000}
Now:
`config.public_file_server.headers = { 'Cache-Control' => 'public,
max-age=31536000' }`
2. Display `static_cache_control` instead of static_cache_control. This
follows what the 2 neighboring methods are doing.
3. Use strip_heredoc to improve the code formatting and readability
like the 2 neighboring methods and wrap to 80 characters.
|
|
|
|
|
|
|
|
| |
As discussed in https://github.com/rails/rails/pull/19135#issuecomment-153385986.
Replaces `serve_static_files` to unify the static options under the `public_file_server` wing.
Deprecates `serve_static_files` accessors, but make them use the newer config internally.
|
|\
| |
| |
| | |
Add basic support for access control headers to ActionDispatch::Static
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now ActionDispatch::Static can accept HTTP headers so that developers
will have control of returning arbitrary headers like
'Access-Control-Allow-Origin' when a response is delivered. They can
be configured through `#config.public_file_server.headers`:
config.public_file_server.headers = {
"Cache-Control" => "public, max-age=60",
"Access-Control-Allow-Origin" => "http://rubyonrails.org"
}
Also deprecate `config.static_cache_control` in favor of
`config.public_file_server.headers`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 37423e4ff883ad5584bab983aceb4b2b759a1fd8.
Jeremy is right that we shouldn't remove this. The fact is that many
engines are depending on this middleware to be in the default stack.
This ties our hands and forces us to keep the middleware in the stack so
that engines will work. To be extremely clear, I think this is another
smell of "the rack stack" that we have in place. When manipulating
middleware, we should have meaningful names for places in the req / res
lifecycle **not** have engines depend on a particular constant be in a
particular place in the stack. This is a weakness of the API that we
have to figure out a way to address before removing the constant.
As far as timing attacks are concerned, we can reduce the granularity
such that it isn't useful information for hackers, but is still useful
for developers.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The runtime header is a potential target for timing attacks since it
returns the amount of time spent on the server (eliminating network
speed). Total time is also not accurate for streaming responses.
The middleware can be added back via:
```ruby
config.middleware.ues ::Rack::Runtime
```
|
| |
| |
| |
| |
| |
| | |
Allocating a new middleware proxy in each application configuration and
then merging the app specific config with the global config when the app
is built.
|
| |
| |
| |
| |
| | |
This can still be added to the middleware stack, but is really not
necessary. I'll follow up with a commit that deprecates the constant
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using the string version of the class reference is now deprecated when
referencing middleware. This should be written as a class not as a string.
Deprecation warning that this change fixes:
```
DEPRECATION WARNING: Passing strings or symbols to the middleware
builder is deprecated, please change
them to actual class references. For example:
"ActionDispatch::ShowExceptions" => ActionDispatch::ShowExceptions
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Specifically, the "loose upgrades" behaviour that allows us to obtain an
exclusive right to load things while other requests are in progress (but
waiting on the exclusive lock for themselves) prevents us from treating
load & unload interchangeably: new things appearing is fine, but they do
*not* expect previously-present constants to vanish.
We can still use loose upgrades for unloading -- once someone has
decided to unload, they don't really care if someone else gets there
first -- it just needs to be tracked separately.
|
| | |
|
|/
|
|
|
| |
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
|
| |
|
|
|
|
| |
when true
|
| |
|
|
|
|
|
|
| |
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"`.
|
|
|
|
| |
This reverts commit a8bf12979e5fa15282b39c8cfa315e663f613539.
|
|
|
|
| |
Provided by sprockets-rails plugin
|
| |
|
| |
|
|
|
|
|
|
| |
Allow static asset serving from env variable (enhanced!)
Conflicts:
railties/CHANGELOG.md
|
| |
|
| |
|
|
|
|
|
|
| |
This is a more conservative approach to 2602a49. Also changed the comment to be
more inline with everything else in the file (describing what the config value
is doing and why). People should just read the docs for alternatives.
|
|
|
|
|
|
|
|
|
| |
This reverts commit 2602a49a8600ab52f807599bbd5b1f9c0be4214f, reversing
changes made to 5d7c1057684c377bc2801c8851e99ff11ab23530.
The explicit default was introduced in 21f6d72, so apps created with Rails < 4
have the commented out version, which means that this change would break those
apps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If code is not eager loaded constants are loaded on demand. Constant
autoloading is not thread-safe, so if eager loading is not enabled
multi-threading should not be allowed.
This showed up in certain Capybara scenarios: Most Capybara drivers
other than Rack::Test need a web server. In particular, drivers for
JavaScript support. Capybara launches WEBrick in its own thread for
those but that per se is fine, because the spec thread and the server
thread are coordinated.
Problem comes if the page being served in the spec makes Ajax calls.
Those may hit WEBrick in parallel, and since WEBrick is multi-threaded
and allow_concurrency? returns true in the test environment before
this patch, threads are spawned to serve those parallel requests. On
the other hand, since eager_load is false by default in the test
environment, constants are not preloaded.
So the suite is autoloading constants in a multi-threaded set. That's
a receipt for paracetamol. The symptom is random obscure errors whose
messages point somehow to constant autoloading.
As a consequence of this fix for allow_concurrency? WEBrick in
Capybara scenarios no longer runs in multi-threaded mode.
Fixes #15089.
|
|
|
|
|
|
| |
Since cc03675d30b58e28f585720dad14e947a57ff5b the error message became like
"Could not load database configuration. No such file -"
which doesn't really tell what's actually missing.
|
| |
|