Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swallow connection errors when sending early hints #1822

Merged
merged 3 commits into from
Aug 1, 2019

Conversation

Jesus
Copy link
Contributor

@Jesus Jesus commented Jun 18, 2019

I've been thinking on how Puma should behave when the early hints
can't be sent because the connection has been lost.

I first thought that it should behave the same way it does when the
connection is lost before main response is sent, I've seen that it
swallows those errors (https://git.io/fjVtg) so perhaps we should do
the same here.

There's one consideration though. Because the early hints are sent at
the very beginning of the app execution, we may want to abort this
request altogether and save resources by throwing an exception and
causing Rails to interrupt execution.

Finally I decided to overlook that case just because I believe it's
least surprising from the Rack app point of view. Also
I haven't seen any other example of the web server interrupting
the apps execution due to an error on the lower layer.

Fixes #1640.

@dentarg
Copy link
Member

dentarg commented Jun 18, 2019

I've seen that it swallows those errors (https://git.io/fjVL8)

Here's the future proof version of that GitHub link.

I've been thinking on how Puma should behave when the early hints
can't be sent because the connection has been lost.

I first thought that it should behave the same way it does when the
connection is lost before main response is sent, I've seen that it
swallows those errors (https://git.io/fjVtg) so perhaps we should do
the same here.

There's one consideration though. Because the early hints are sent at
the very beginning of the app execution, we may want to abort this
request altogether and save resources by throwing an exception and
causing Rails to interrupt execution.

Finally I decided to overlook that case just because I believe it's
least surprising from the Rack app point of view. Also
I haven't seen any other example of the web server interrupting
the apps execution due to an error on the lower layer.

Fixes puma#1640.
@Jesus
Copy link
Contributor Author

Jesus commented Jun 18, 2019

I've updated both the Github message & the commit message with your link. Thank you!

@nateberkopec
Copy link
Member

Works for me. I think you could write a test that just has fast_write blow up/raise.

@nateberkopec nateberkopec added the waiting-for-changes Waiting on changes from the requestor label Jul 16, 2019
@Jesus
Copy link
Contributor Author

Jesus commented Jul 24, 2019

Test added and I think this is ready to merge 🚢

@nateberkopec nateberkopec removed the waiting-for-changes Waiting on changes from the requestor label Jul 28, 2019
@nateberkopec nateberkopec added this to the 4.1.0 milestone Jul 28, 2019
@nateberkopec nateberkopec merged commit 2deaf77 into puma:master Aug 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Early hints + javascript_include_tag = Puma:ConnectionError
3 participants