| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
update the tests, using an if-else
|
| |
|
|
|
|
| |
avoid freezing the headers until the web server has actually read data
from the body proxy. Once the webserver has read data, then we should
throw an error if someone tries to set a header
|
| |
|
|
|
|
|
|
|
|
|
| |
when streaming responses, we need to make sure the cookie jar is written
to the headers before returning up the stack. This commit introduces a
new method on the response object that writes the cookie jar to the
headers as the response is committed. The middleware and test framework
will not write the cookie headers if the response has already been
committed.
fixes #14352
|
| | |
|
| |
|
|
|
|
| |
when an exception happens in an action before the response has been
committed, then we should re-raise the exception in the main thread.
This lets us reuse the existing exception handling.
|
| |
|
|
|
|
| |
detect the type of controller we're testing and return the right type of
response based on that controller. This allows us to stop doing the
weird sleep thing.
|
| |
|
|
| |
callback and an error happens
|
| |
|
|
|
|
| |
if the controller action has not yet streamed any data, actions should
process as normal, and errors should trigger the appropriate behavior
(500, or in the case of ActionController::BadRequest, a 400 Bad Request)
|
| |\
| |
| | |
SSE class for ActionController::Live
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
Without timeout:
this test executed infinitely on JRuby
Passes on MRI
With Timeout:
this test gracefully fails on JRuby
Passes on MRI, tested on v2.0 & v1.9.3
|
| |
|
|
|
|
|
|
|
| |
Any exceptions that occured at the view or controller level for a
controller using ActionController::Live would cause the server to either
hang with an open socket indefinitely, or immediately crash (depending
on whether the server was launched with rails s or directly). Changed
the behavior of exceptions to act the same as streaming templates for
html requests, and allow for an on_error callback if needed.
|
| |
|
|
| |
stale on live streams(issue #9636)
|
| | |
|
| | |
|
| |
|
|
| |
will work
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
responses.
Processing controller actions in a separate thread allows us to work
around the rack api - we can allow the user to set status and headers,
then block until the first bytes are written. As soon as the first
bytes are written, the main thread can return the status, headers, and
(essentially) a queue for the body.
|
| |
|
