-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Sinatra completely incompatible with HTTP gem. #881
Comments
Bringing in @tarcieri since it's his gem. |
Got a link to the relevant Sinatra code? |
Here's an example of the error:
|
Looks like the "handler" might be getting set to https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1435 |
The primary prefernece issue is here: https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1862 |
@tarcieri Yep, based on the preference. The preference by default defines two "servers": "HTTP" and "webrick". It then goes over each of those server "names" and feeds them to Rack::Handler (helpfully swallowing up errors): https://github.com/sinatra/sinatra/blob/master/lib/sinatra/base.rb#L1766 |
What else is |
I think this is a bug in Rack. It should check for The relevant code is in rack/handler. |
Alright, I'll bring it up with them and submit a PR. Thanks! On Fri, Jun 6, 2014 at 4:07 PM, Konstantin Haase notifications@github.com
Kurtis Rainbolt-Greene, Hacker |
….rb on clean Windows install. See workaround at: http://stackoverflow.com/questions/17334734/how-do-i-get-sinatra-to-work-with-httpclient And related issue related to Sinatra at: sinatra/sinatra#881
Not sure this is something we can fix in Sinatra, giving it a close. Please feel free to discuss this issue on Rack. |
The http.gem defines a top level
HTTP
constant, a module.Sinatra looks for a top level
HTTP
constant and callsrun
on it, regardless of if you want it to do that.This is pretty weird and I'm going to say, since top level constants (in my opinion) should be reserved for namespaces that the http.gem wins.
Why is Sinatra doing this possibly dangerous thing on a global constant? What if there's an HTTP constant with a
.run
method that does something the user doesn't want to do?The text was updated successfully, but these errors were encountered: