Reputation: 467
I'm constantly getting this error in rails server log:
Invalid request: Invalid HTTP format, parsing fails.
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/thin-1.6.1/lib/thin/request.rb:84:in `execute'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/thin-1.6.1/lib/thin/request.rb:84:in `parse'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/thin-1.6.1/lib/thin/connection.rb:41:in `receive_data'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/faye-websocket-0.7.2/lib/faye/adapters/thin.rb:44:in `receive_data'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/thin-1.6.1/lib/thin/backends/base.rb:73:in `start'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/thin-1.6.1/lib/thin/server.rb:162:in `start'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/rack-1.5.2/lib/rack/handler/thin.rb:16:in `run'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/rack-1.5.2/lib/rack/server.rb:264:in `start'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/railties-4.0.1/lib/rails/commands/server.rb:84:in `start'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/railties-4.0.1/lib/rails/commands.rb:76:in `block in <top (required)>'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/railties-4.0.1/lib/rails/commands.rb:71:in `tap'
/home/budkin/gamestown/vendor/cache/ruby/2.0.0/gems/railties-4.0.1/lib/rails/commands.rb:71:in `<top (required)>'
bin/rails:4:in `require'
bin/rails:4:in `<main>'
everything works fine, but the errors are just annoying
Yes, this is on thin
Upvotes: 27
Views: 21155
Reputation: 111
Had the same issue with a thin server.
I threw a binding.pry in thin's request.rb file and found that the following request was causing the error:
GET /info?txtAirPlay&txtRAOP RTSP/1.0\r\n\r\n
It turns out that this could be an issue with Yosemite (I'm running 10.10.3) and the localhost port that you're running. I'm running on port 5000 and if you look at the following stack overflow post, you'll see that Apple AirTunes is running on port 5000: AirPlay messes up localhost
Try changing your rails server port to get rid of the error (I just picked 5212 randomly):
rails s -p 5212
Upvotes: 8
Reputation: 1521
For Chrome user:
Chrome is enforcing HTTPS instead of HTTP which causes this issue. Click info icon
next to url and change Pop-ups and redirects
to Block
should make it work again.
Upvotes: 0
Reputation: 161
You can use Ngrok
First, run development server with ENV as production
and then execute following command ./ngrok http -bind-tls=true localhost:3000
Upvotes: 1
Reputation: 486
In my case this was related to Chrome enforcing HSTS on localhost. I used this answer to fix:
Upvotes: 3
Reputation: 406
I had visited https://localhost:3000 during a debugging session of rails s -e production, which has config.force_ssl = true.
This forced the latest version of chrome to only attempt to visit https://localhost:3000.com even when I specifically entered http://localhost:3000.
If your application is working in Incognito mode or a different browser. I would suggest clearing your browsing history.
After a binding.pry in the thin server. I was receiving @data encryption of:
0\tlocalhost\x00\x17\x00\x00\x00#\x00\x00\x00\r\x00\x12\x00\x10\x06\x01\x06\x03\x05\x01\x05\x03\x04\x01\x04\x03\x02\x01\x02\x03\x00\x05\x00\x05\x01\x00\x00\x00\x00\x00\x12\x00\x00\x00\x10\x00\x0E\x00\f\x02h2\bhttp/1.1uP\x00\x00\x00\v\x00\x02\x01\x00\x00\n\x00\b\x00\x06\x00\x1D\x00\x17\x00\x18
Upvotes: 9
Reputation: 59
if you comment it config.force_ssl = true
and error still apearing - check you request in browser it could be still https
Upvotes: 1
Reputation: 5458
gem thin
gem 'thin', group: :development
rake tmp:clear
and clear your browser' cacheUpvotes: 4
Reputation: 211
I had the exact same error as above. In my case it was a (.net) client that was attempting to connect to my (thin) server using HTTPS instead of HTTP. As soon as I changed the protocol back to basic http, the error went away.
Upvotes: 20