-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Internal Sinatra errors now extend Sinatra::Error #1519
Conversation
@namusyaka, @mwpastore any thoughts on the impact of this change? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This is an alternative solution to #1236. |
(I opened #1518.) I don't know Sinatra's internals, but from the diff this does seem to address exactly the issue I was reporting! |
I need to take a closer look at the implementation and consider unintended side effects, but at first blush this is a much better approach than what I've proposed in #1236. |
By extending Sinatra::Error, an error class can set the http status code on the response to a value other than 500. This commit fixes issues sinatra#1204 and sinatra#1518 where an error raised by a third party library that responded to http_status could set the status on the response. Any error outside of Sinatra errors will now always return a 500 status. This fixes an issue where an exception could leak sensitive data in the message to the browser. Errors that have http_status code 400 or 404 use the message as the body of the response. This is why it is imperative that these errors extend Sinatra::Error so that this is an explicit decision.
See: sinatra/sinatra#1774 See: sinatra/sinatra#1519 Signed-off-by: matoro <matoro@users.noreply.github.com>
This is in master as bda8c29 (this was merged into the unstable branch that we don't use anymore so GitHub doesn't have the correct reference here) |
@dentarg is there something that needs to be done here? |
See: sinatra/sinatra#1774 See: sinatra/sinatra#1519 Signed-off-by: matoro <matoro@users.noreply.github.com>
Upstream determined this will go into 3.0.0 release, so it's still required for 2.2.1. See: sinatra/sinatra#1774 See: sinatra/sinatra#1519 Signed-off-by: Matoro Mahri <matoro@users.noreply.github.com>
See: sinatra/sinatra#1774 See: sinatra/sinatra#1519 Signed-off-by: matoro <matoro@users.noreply.github.com> Signed-off-by: Matt Turner <mattst88@gentoo.org>
Upstream determined this will go into 3.0.0 release, so it's still required for 2.2.1. See: sinatra/sinatra#1774 See: sinatra/sinatra#1519 Signed-off-by: Matoro Mahri <matoro@users.noreply.github.com> Signed-off-by: Matt Turner <mattst88@gentoo.org>
Upgrading Sinatra has broken HTTP status codes for some errors. There was a Sinatra change sinatra/sinatra#1519 in V3 (SequenceServer has gone from v2 -> V4 recently) that made the http status code setting from the exception class more explicit
By extending
Sinatra::Error
, an error class can set the http status code on the response to a value other than 500. This commit fixes issues #1204 and #1518 where an error raised by a third party library that responded to http_status could set the status on the response. Any error outside of Sinatra errors will now always return a 500 status.This fixes an issue where an exception could leak sensitive data in the message to the browser. Errors that have http_status code 400 or 404 use the message as the body of the response. This is why it is imperative that these errors extend Sinatra::Error so that this is an explicit decision.