| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes: https://github.com/rails/rails/issues/16433.
|
|
|
|
|
|
| |
Allow static asset serving from env variable (enhanced!)
Conflicts:
railties/CHANGELOG.md
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
After
https://github.com/rack/rack/commit/12528d4567d8e6c1c7e9422fee6cd8b43c4389bf
ETag will include a `W/` before the digest.
|
|\
| |
| | |
Move Rack::Cache after ActionDispatch::Static in the middleware stack
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
| |
As this middleware comes by default in a new
rails app
Added test to check omit for CheckPending when
Active Record is not included.
|
|
|
|
| |
Rack::Sendfile is loaded by default now
|
|
|
|
| |
reflect that
|
|
|
|
|
| |
Rails.application when drawing routes and creating other configurations
on the application.
|
| |
|
|
|
|
|
| |
Since the Rack::Lock still exists in development,
let's provide a way to disable it explicitly.
|
| |
|
|
|
|
|
| |
Setting the action_dispatch.rack_cache options to true or a hash should
be the way to enable it.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The flag was mainly used to add a Rack::Lock middleware to
the stack, but the only scenario the lock is desired is in
development.
If you are deploying on a not-threaded server, the Rack::Lock
does not provide any benefit since you don't have concurrent
accesses. On the other hand, if you are on a threaded server,
you don't want the lock, since it defeats the purpose of using
a threaded server.
If there is someone out there, running on a thread server
and does want a lock, it can be added to your environment
as easy as: `use Rack::Lock`
|
|
|
|
| |
Closes #7110 there's more work to do on rack-cache issue 69
|
|
|
|
|
|
| |
So apps that accidentally add middlewares later aren't unwittingly dumping them in a black hole.
Closes #5911
|
| |
|
| |
|
|
|
|
|
|
| |
generator options
[Carlos Antonio da Silva & Santiago Pastorino]
|
| |
|
|
|
|
| |
[Carlos Antonio da Silva & Santiago Pastorino]
|
| |
|
|
|
|
|
|
|
|
| |
This makes rails behave properly when you serve static assets
and you have X-Sendfile headers enabled. Nevertheless in most
cases you should not rely on that and serve static assets with
a webserver like Apache or Nginx (as you already have it in
place anyway if you use X-Sendfile)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This behaves similarly to REQUEST_URI, but
we need to implement it on our own because
REQUEST_URI is not reliable.
Note that since PATH_INFO does not contain
information about trailing question mark,
this is not 100% accurate, for example
`/foo?` will result in `/foo` in ORIGINAL_FULLPATH
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
config.action_dispatch.x_sendfile_header is set
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Broke in 0e1dcae1857db4f6721561caff38d8be748d0b40
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
if set to true
This will allow user to be able to force all requests to be under HTTPS protocol.
This commit was a request from DHH. Special thanks to Josh Peek as well for making `Rack::SSL`.
|
|
|
|
| |
This will make sure the application will raise `ActionController::RoutingError` in case "X-Cascade: pass" header was set, usually when there's no route match.
|
|
|
|
| |
gets included.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
activerecord/lib/active_record/associations/association_proxy.rb
activerecord/lib/active_record/autosave_association.rb
activerecord/lib/active_record/base.rb
activerecord/lib/active_record/persistence.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Based on the implementation on the 2-3-stable branch, patches by Hongli
Lai <hongli@phusion.nl>, and helpful suggestions from José Valim.
Hongli Lai's patches included locking around the request cycle; this is
now handled by Rack::Lock (https://github.com/rack/rack/issues/issue/87/).
[#2873]
Signed-off-by: José Valim <jose.valim@gmail.com>
|