Invalid request: Invalid HTTP format, parsing fail

Question

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

Answer 1

1. Are you using gem thin
2. If so make sure it's in the right environment in your Gemfile gem 'thin', group: :development
3. Else: Try to open http://localhost:3000 on other browsers.... or if you only have only one browser... you could open an 'incognito' or 'private' window
4. If it's work on other browser then you need to rake tmp:clear and clear your browser' cache

Answer 2

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

Answer 3

if you comment it config.force_ssl = true and error still apearing - check you request in browser it could be still https

Answer 4

In my case this was related to Chrome enforcing HSTS on localhost. I used this answer to fix:

1. Surf to chrome://net-internals/#hsts
2. In the delete section, enter "localhost" and delete the record from Chrome.

Answer 5

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

Answer 6

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.