| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Forgot to do it in 748b2f9, when deprecating `serve_static_files`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
We don't need to fully disable concurrent requests: just ensure that
loads are performed in isolation.
|
|
|
|
| |
when true
|
|
|
|
| |
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
|