[Faye::RackAdapter] input must be a string or IO

[Matt Smith]

Not sure why I am getting this. The line 23 is the listen line in the faye.ru file. faye.listen(9292) is in the example documentation.

My application logic is all tested, but I am having to do some debugging as I am transition to a production environment. What does this error mean and why am I getting it?

17:18:31 faye.1       | 2012-04-30 17:18:31 [ERROR] [Faye::RackAdapter] input must be a string or IO

17:18:31 faye.1       | Backtrace:

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/yajl-ruby-1.1.0/lib/yajl.rb:36:in `parse'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/yajl-ruby-1.1.0/lib/yajl.rb:36:in `parse'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/lib/faye/adapters/rack_adapter.rb:98:in `handle_request'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/lib/faye/adapters/rack_adapter.rb:91:in `call'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:80:in `block in pre_process'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:78:in `catch'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:78:in `pre_process'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:53:in `process'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-websocket-0.4.5/lib/faye/adapters/thin.rb:41:in `process'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:38:in `receive_data'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-websocket-0.4.5/lib/faye/adapters/thin.rb:45:in `receive_data'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.beta.4/lib/eventmachine.rb:179:in `run_machine'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.beta.4/lib/eventmachine.rb:179:in `run'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/base.rb:61:in `start'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/server.rb:159:in `start'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/lib/rack/handler/thin.rb:13:in `run'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/lib/faye/adapters/rack_adapter.rb:54:in `listen'

17:18:31 faye.1       | ./faye.ru:23:in `block in <main>'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in `instance_eval'

17:18:31 faye.1       | /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in `initialize'

17:18:31 faye.1       | ./faye.ru:1:in `new'

17:18:31 faye.1       | ./faye.ru:1:in `<main>'

# faye.ru - (simplified - minus extensions)

$stdout.sync = true

require 'faye'

require File.expand_path('../config/initializers/faye.rb', __FILE__)

Faye::Logging.log_level = :info

Faye.logger = lambda { |m| puts m }

Faye::WebSocket.load_adapter 'thin'

faye = Faye::RackAdapter.new(:mount => '/faye', :timeout => 45)

faye.listen(9292)

run faye

[Raphael Randschau]

I'm seeing the exact same issues when running private_pub over HTTPS.
Clues on how to fix this would be greatly appreciated!

On May 1, 2:28 am, Matt Smith <m...@nearapogee.com> wrote:
> Not sure why I am getting this. The line 23 is the listen line in the
> faye.ru file. faye.listen(9292) is in the example documentation.
>
> My application logic is all tested, but I am having to do some debugging as
> I am transition to a production environment. What does this error mean and
> why am I getting it?
>
> 17:18:31 faye.1       | 2012-04-30 17:18:31 [ERROR] [Faye::RackAdapter]
> input must be a string or IO
> 17:18:31 faye.1       | Backtrace:
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/yajl-ruby-1. 1.0/lib/yajl.rb:36:in

> `parse'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/yajl-ruby-1. 1.0/lib/yajl.rb:36:in

> `parse'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/l ib/faye/adapters/rack_adapter.rb:98:in

> `handle_request'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/l ib/faye/adapters/rack_adapter.rb:91:in

> `call'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/l ib/thin/connection.rb:80:in

> `block in pre_process'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/l ib/thin/connection.rb:78:in

> `catch'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/l ib/thin/connection.rb:78:in

> `pre_process'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/l ib/thin/connection.rb:53:in

> `process'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-websock et-0.4.5/lib/faye/adapters/thin.rb:41:in

> `process'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/l ib/thin/connection.rb:38:in

> `receive_data'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-websock et-0.4.5/lib/faye/adapters/thin.rb:45:in

> `receive_data'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/eventmachine -1.0.0.beta.4/lib/eventmachine.rb:179:in

> `run_machine'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/eventmachine -1.0.0.beta.4/lib/eventmachine.rb:179:in

> `run'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/l ib/thin/backends/base.rb:61:in

> `start'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/l ib/thin/server.rb:159:in

> `start'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/l ib/rack/handler/thin.rb:13:in

> `run'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/l ib/faye/adapters/rack_adapter.rb:54:in

> `listen'
> 17:18:31 faye.1       | ./faye.ru:23:in `block in <main>'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/l ib/rack/builder.rb:51:in

> `instance_eval'
> 17:18:31 faye.1       |

> /home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/l ib/rack/builder.rb:51:in

[Raphael Randschau]

Oh, some details:

I'm running private_pub 157daa14dbdf30fe5911998989e24e9aac96133f, with
the require 'uri' and require 'net/https' patch on MRI 1.9.3-p125.

[GT]

This is something I'm also interested in. I'm running faye 0.8.2
( latest if I'm not mistaken ), and this error is reproducible on
Heroku.

[James Coglan]

On 1 May 2012 01:28, Matt Smith <ma...@nearapogee.com> wrote:

Not sure why I am getting this. The line 23 is the listen line in the faye.ru file. faye.listen(9292) is in the example documentation.

My application logic is all tested, but I am having to do some debugging as I am transition to a production environment. What does this error mean and why am I getting it?

The error is from Yajl trying to parse something that is not a string or IO object. It's originating here:

https://github.com/faye/faye/blob/0.8.2/lib/faye/adapters/rack_adapter.rb#L98

This means the method `message_from_request` cannot determine how to extract the JSON payload from the request. This method is here:

https://github.com/faye/faye/blob/0.8.2/lib/faye/adapters/rack_adapter.rb#L167-181

Take a look at the contents of `request.env` in that method. The method's output is a function of the request's content-type, its query string and body.

Stack trace included below.

[Raphael Randschau]

I've added some output to the methods in question:

def handle_request(request)

      json_msg = message_from_request(request)

      p "message from request: '#{json_msg}' class:'#{json_msg.class}'"

      # the rest of the original method...

 

As well as

def message_from_request(request)

      p "request.env #{request.env.to_yaml}"

      p "request.body #{request.body.to_yaml}" 

      # the rest of the original method... 

Here's the request.env of the problematic request:

"request.env ---

SERVER_SOFTWARE: thin 1.3.1 codename Triple Espresso

SERVER_NAME: !binary |-

  YmV0YW5kc2xlZXAuY29t

rack.input: !ruby/object:StringIO {}

rack.version:

- 1

- 0

rack.errors: !ruby/object:IO {}

rack.multithread: false

rack.multiprocess: false

rack.run_once: false

!binary \"UkVRVUVTVF9NRVRIT0Q=\": !binary |-

  R0VU

!binary \"UkVRVUVTVF9QQVRI\": !binary |-

  L2ZheWU=

!binary \"UEFUSF9JTkZP\": !binary |-

  L2ZheWU=

!binary \"UkVRVUVTVF9VUkk=\": !binary |-

  L2ZheWU=

!binary \"SFRUUF9WRVJTSU9O\": !binary |-

  SFRUUC8xLjA=

!binary \"SFRUUF9YX1JFQUxfSVA=\": !binary |-

  NDYuMTQyLjUxLjEwNg==

!binary \"SFRUUF9YX0ZPUldBUkRFRF9GT1I=\": !binary |-

  NDYuMTQyLjUxLjEwNg==

!binary \"SFRUUF9IT1NU\": !binary |-

  YmV0YW5kc2xlZXAuY29tOjQ0NDM=

!binary \"SFRUUF9DT05ORUNUSU9O\": !binary |-

  Y2xvc2U=

!binary \"SFRUUF9PUklHSU4=\": !binary |-

  aHR0cHM6Ly9iZXRhbmRzbGVlcC5jb20=

!binary \"SFRUUF9TRUNfV0VCU09DS0VUX0tFWQ==\": !binary |-

  NjkzM1p6MSsreTRJUWNhR3ZJTy9RZz09

!binary \"SFRUUF9TRUNfV0VCU09DS0VUX1ZFUlNJT04=\": !binary |-

  MTM=

!binary \"SFRUUF9TRUNfV0VCU09DS0VUX0VYVEVOU0lPTlM=\": !binary |-

  eC13ZWJraXQtZGVmbGF0ZS1mcmFtZQ==

!binary \"SFRUUF9DT09LSUU=\": !binary |-

  X3Nlc3Npb25faWQ9OTNlYjcxMjNlZmU5MmI5ODA0YTM3ZDdiM2ZhMDM2YzY7

  IF9ibnMtYmFja2VuZC1hcHBfc2Vzc2lvbj1CQWg3QjBraUQzTmxjM05wYjI1

  ZmFXUUdPZ1pGUmtraUpXVmhOR1k0WW1Jd01USmxOMk0xWVdaaU56ZGxPRGd5

  TTJZd09XTXlZVEZoQmpzQVZFa2lFRjlqYzNKbVgzUnZhMlZ1QmpzQVJra2lN

  VVJuYm05eGMycHZNSEZEZG5kRmNWVjVla3RzSzFVdlVtRmhMMDgyUlVvd2JU

  RkpNekJRY0dkWlUzYzlCanNBUmclM0QlM0QtLTdkYTgzNjg0MzEwM2VkOGMx

  Mjk4OGU3YTU3MTgzMGJlMmZkMzcyMjA=

!binary \"R0FURVdBWV9JTlRFUkZBQ0U=\": !binary |-

  Q0dJLzEuMg==

!binary \"U0VSVkVSX1BPUlQ=\": !binary |-

  NDQ0Mw==

!binary \"UVVFUllfU1RSSU5H\": !binary \"\"

!binary \"U0VSVkVSX1BST1RPQ09M\": !binary |-

  SFRUUC8xLjE=

!binary \"cmFjay51cmxfc2NoZW1l\": https

!binary \"U0NSSVBUX05BTUU=\": !binary \"\"

REMOTE_ADDR: !binary |-

  MTkyLjE2OC4wLjE=

async.callback: !ruby/object:Method {}

async.close: !ruby/object:EventMachine::DefaultDeferrable {}"

As well as the request.body:

"request.body --- !ruby/object:StringIO {}"

And the parsed result:

"message from request: '' class:'NilClass'"

The problem seems to be that CGI.parse(request.body.read)['message'][0] returns nil, because request.body is empty. I'm not sure why this happens at all because I'm using the Faye.js client as it's served by the application...

Any suggestions on how to fix this?

[Matt Smith]

> The problem seems to be that CGI.parse(request.body.read)['message'][0]
> returns nil, because request.body is empty. I'm not sure why this happens at
> all because I'm using the Faye.js client as it's served by the
> application...
> Any suggestions on how to fix this?

I too looked at the request, and saw nothing strange. I fiddled for a
while over the weekend with this. And got it working once, but then it
started failing again. I have analysed all my input to faye, and I am
not sure where this is coming from. So I decided to eliminate
variables, I decided to go back to basics and try the js console, I
don't think it can get much simpler than this.

It appears that a simple subscribe can cause the error:

var client = new Faye.Client('http://project.dev/faye');
client.subscribe('/messages', function(message) {
alert('Got a message: ' + message.text);
});

Results in this:

09:51:41 faye.1 |
[{"channel":"/meta/handshake","version":"1.0","supportedConnectionTypes":["long-polling"],"id":"1"}]
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Processing messages:
[{"channel":"/meta/handshake","version":"1.0","supportedConnectionTypes":["long-polling"],"id":"1"}]
(local: false)
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Handling message:
{"channel":"/meta/handshake","version":"1.0","supportedConnectionTypes":["long-polling"],"id":"1"}
(local: false)
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Returning replies:
[{"id":"1","channel":"/meta/handshake","successful":true,"version":"1.0","supportedConnectionTypes":["long-polling","cross-origin-long-polling","callback-
polling","websocket","eventsource","in-process"],"clientId":"7dk9hjhgcuj9subgp5ewtzs9t","advice":{"reconnect":"retry","interval":0,"timeout":45000}}]
09:51:41 faye.1 |
09:51:41 faye.1 | 2012-05-07 09:51:41 [ERROR]

[Faye::RackAdapter] input must be a string or IO

09:51:41 faye.1 | Backtrace:
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/yajl-ruby-1.1.0/lib/yajl.rb:36:in
`parse'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/yajl-ruby-1.1.0/lib/yajl.rb:36:in
`parse'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/lib/faye/adapters/rack_adapter.rb:99:in
`handle_request'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/lib/faye/adapters/rack_adapter.rb:91:in
`call'
09:51:41 faye.1 |

/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:80:in
`block in pre_process'

09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:78:in
`catch'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:78:in
`pre_process'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:53:in
`process'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-websocket-0.4.5/lib/faye/adapters/thin.rb:41:in
`process'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/connection.rb:38:in
`receive_data'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-websocket-0.4.5/lib/faye/adapters/thin.rb:45:in
`receive_data'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.beta.4/lib/eventmachine.rb:179:in
`run_machine'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/eventmachine-1.0.0.beta.4/lib/eventmachine.rb:179:in
`run'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/base.rb:61:in
`start'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/server.rb:159:in
`start'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/lib/rack/handler/thin.rb:13:in
`run'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/faye-0.8.2/lib/faye/adapters/rack_adapter.rb:54:in
`listen'
09:51:41 faye.1 | ./faye.ru:23:in `block in <main>'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in
`instance_eval'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in
`initialize'
09:51:41 faye.1 | ./faye.ru:1:in `new'
09:51:41 faye.1 | ./faye.ru:1:in `<main>'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/rack/adapter/loader.rb:36:in
`eval'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/rack/adapter/loader.rb:36:in
`load'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/controllers/controller.rb:181:in
`load_rackup_config'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/controllers/controller.rb:71:in
`start'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:185:in
`run_command'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:151:in
`run!'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/thin-1.3.1/bin/thin:6:in
`<top (required)>'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/bin/thin:23:in `load'
09:51:41 faye.1 |
/home/matt/.rbenv/versions/1.9.3-p194/bin/thin:23:in `<main>'
09:51:41 faye.1 |
[{"channel":"/meta/subscribe","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","subscription":"/messages","id":"2"},{"channel":"/meta/connect","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","connectionType":"long-polling","id":"3","a
dvice":{"timeout":0}}]
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Processing messages:
[{"channel":"/meta/subscribe","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","subscription":"/messages","id":"2"},{"channel":"/meta/connect","clientId":"7dk9hjh
gcuj9subgp5ewtzs9t","connectionType":"long-polling","id":"3","advice":{"timeout":0}}]
(local: false)
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Handling message:
{"channel":"/meta/subscribe","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","subscription":"/messages","id":"2"}
(local: false)
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Returning replies:
[{"id":"2","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","channel":"/meta/subscribe","successful":true,"subscription":"/messages"}]
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Handling message:
{"channel":"/meta/connect","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","connectionType":"long-polling","id":"3","advice":{"timeout":0}}
(local: false)
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Returning replies:
[{"id":"2","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","channel":"/meta/subscribe","successful":true,"subscription":"/messages"},{"id":"3","clientId":"7dk9hjhg
cuj9subgp5ewtzs9t","channel":"/meta/connect","successful":true,"advice":{"reconnect":"retry","interval":0,"timeout":45000}}]
09:51:41 faye.1 |
[{"channel":"/meta/connect","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","connectionType":"eventsource","id":"4"}]
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Processing messages:
[{"channel":"/meta/connect","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","connectionType":"eventsource","id":"4"}]
(local: false)
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Handling message:
{"channel":"/meta/connect","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","connectionType":"eventsource","id":"4"}
(local: false)
09:51:41 faye.1 | 2012-05-07 09:51:41 [INFO] [Faye::Server]
Returning replies:
[{"id":"4","clientId":"7dk9hjhgcuj9subgp5ewtzs9t","channel":"/meta/connect","successful":true,"advice":{"reconnect":"retry","interval":45000,"timeout":0}}
]

Thanks for looking into this!

[Matt Smith]

On Mon, May 7, 2012 at 10:18 AM, Matt Smith <ma...@nearapogee.com> wrote:
>> The problem seems to be that CGI.parse(request.body.read)['message'][0]
>> returns nil, because request.body is empty. I'm not sure why this happens at
>> all because I'm using the Faye.js client as it's served by the
>> application...
>> Any suggestions on how to fix this?
>
> I too looked at the request, and saw nothing strange. I fiddled for a
> while over the weekend with this. And got it working once, but then it
> started failing again. I have analysed all my input to faye, and I am
> not sure where this is coming from. So I decided to eliminate
> variables, I decided to go back to basics and try the js console, I
> don't think it can get much simpler than this.
>
> It appears that a simple subscribe can cause the error:
>
> var client = new Faye.Client('http://project.dev/faye');
> client.subscribe('/messages', function(message) {
>  alert('Got a message: ' + message.text);
> });

I forgot to mention I get this in the JS console:
Unexpected response code: 400

(using 0.8.2)

[Raphael Randschau]

I'm receiving the same error in the JS Console - other Websocket-clients (like SocketRocket for iOS) receive the same error so it's most likely not related to the JS implementation but rather the Server.

Downgrading to faye 0.8 does not fix the problem. I've not tried downgrading faye-websocket, tho.

[Matt Smith]

I too looked at the request, and saw nothing strange. I fiddled for a
while over the weekend with this. And got it working once, but then it
started failing again. I have analysed all my input to faye, and I am
not sure where this is coming from. So I decided to eliminate
variables, I decided to go back to basics and try the js console, I
don't think it can get much simpler than this.

As usual I think the root issue is usually just slightly out of scope of this conversation. I tested my app hitting faye running on thin on port 9292. I started to see problems when I started proxy_pass'ing to thin through nginx. It appears websockets/tcp proxies are not native features supported in nginx. I would like to hear if the other experiencing this are attempting this as well. (Not sure what the solution will be for the heroku guys.)

Fortunately, Weibin Yao made the nginx_tcp_proxy_module <https://github.com/yaoweibin/nginx_tcp_proxy_module>. I am going to give this a go, probably the develop branch. I, hopefully, will be able to get to this by today and post back, but I may need to knock a few other things off my checklist first.

[Raphael Randschau]

Interesting, I'm also using nginx as reverse proxy in my production environment, maybe I should try out Apache for one just to see if that fixes my problem. 

Another production site which I'm running without faye-websockets does not use a reverse proxy in front of thin and I'm not having any issues there.

I'll give Apache a spin and report back, would be great if we managed to come up with different solutions!

[Raphael Randschau]

According to https://groups.google.com/forum/?fromgroups#!topic/faye-users/RjLzvn4EeyQ

Apache won't work, but HAProxy should. So, I'll test against HAProxy... ;)

[James Coglan]

This request looks odd, as though the HTTP parser is acting on still-encrypted data rather than getting fully decrypted data from the HTTPS connection.

[James Coglan]

On 7 May 2012 18:18, Matt Smith <ma...@nearapogee.com> wrote:

It appears that a simple subscribe can cause the error:

var client = new Faye.Client('http://project.dev/faye');
client.subscribe('/messages', function(message) {
 alert('Got a message: ' + message.text);
});

I've tried this, I can't reproduce the problem using the code you've given me. Some notes on your faye.ru:

What's going on in this line? There must be code in here affecting the app, or some other intermediary or side effect is breaking the requests.

require File.expand_path('../config/initializers/faye.rb', __FILE__)

These lines are redundant: either this is a normal Ruby script and you call faye.listen(), or it's a Rackup script and you use the normal rackup API, not both.

faye.listen(9292)

run faye

How are you running this file on the command line?

[James Coglan]

On 7 May 2012 18:20, Matt Smith <ma...@nearapogee.com> wrote:

I forgot to mention I get this in the JS console:

Unexpected response code: 400

This is caused by the server refusing to accept WebSocket connections. You can't silence it (that I know of) and it should not affect Faye's functioning since it falls back to other transports.

It seems odd that this would happen on a bare Faye server though, it ought to be happy processing WebSocket unless something environmental is preventing it. Like I said -- what do you have in your initializers, how are you running the app on the command line, and are there any proxies between Faye and the browser?

[James Coglan]

On 8 May 2012 16:25, Matt Smith <ma...@nearapogee.com> wrote:

As usual I think the root issue is usually just slightly out of scope of this conversation. I tested my app hitting faye running on thin on port 9292. I started to see problems when I started proxy_pass'ing to thin through nginx.

Yes, nginx does not support WebSocket, and that's why you'll see 'Unexpected response code 400' in your JS console. There's a chance this proxy is also responsible for messing up rack.input, though that seems unlikely. 

[Matt Smith]

> Yes, nginx does not support WebSocket, and that's why you'll see 'Unexpected
> response code 400' in your JS console. There's a chance this proxy is also
> responsible for messing up rack.input, though that seems unlikely.

Yeah. I realized that. So is Bayeux a subset of WebSocket? (I have not
read through all the specification and implementation yet. Only so
much time in a day....)

I think I am going to go to a more elaborate environment with Stunnel
and Haproxy in front of nginx and thin. I need faye over SSL, as well.
I am a bit new to Stunnel and Haproxy, but I think it should work from
what I have read. Overall, it will simplify my nginx config quite a
lot I think.

[Raphael Randschau]

Luckily we were able to fix our problem using a combination of stunnel and haproxy.

The basic setup is this:

stunnel -> haproxy -> faye ( for ws and non-ws requests )

and 

stunnel -> haproxy -> nginx -> puma ( for rails and the likes )

faye runs using thin, and thin is configured without ssl since that is what stunnel is for.

Works like a charm! Hope you can fix your issues as well.

[James Coglan]

On 10 May 2012 01:46, Matt Smith <ma...@nearapogee.com> wrote:

> Yes, nginx does not support WebSocket, and that's why you'll see 'Unexpected
> response code 400' in your JS console. There's a chance this proxy is also
> responsible for messing up rack.input, though that seems unlikely.

Yeah. I realized that. So is Bayeux a subset of WebSocket? (I have not
read through all the specification and implementation yet. Only so
much time in a day....)

No, Bayeux is a JSON-based messaging protocol that can be implemented on top of a variety of network protocols, including HTTP and WebSocket. So, HTTP and WebSocket sit on top of TCP, and Bayeux sits on top of *those*.

 

I think I am going to go to a more elaborate environment with Stunnel
and Haproxy in front of nginx and thin. I need faye over SSL, as well.
I am a bit new to Stunnel and Haproxy, but I think it should work from
what I have read. Overall, it will simplify my nginx config quite a
lot I think.

I've certainly heard people having success with STunnel in front of Faye for their SSL setup. 

[James Coglan]

On 10 May 2012 10:38, Raphael Randschau <rrand...@weluse.de> wrote:

Luckily we were able to fix our problem using a combination of stunnel and haproxy.

The basic setup is this:

stunnel -> haproxy -> faye ( for ws and non-ws requests )

and 

stunnel -> haproxy -> nginx -> puma ( for rails and the likes )

This sounds sensible. Faye's WebSocket library works under HAProxy, even if you're running it in http mode. 

[Matt Smith]

What's going on in this line? There must be code in here affecting the app, or some other intermediary or side effect is breaking the requests.

require File.expand_path('../config/initializers/faye.rb', __FILE__)

That initializer parses a yaml file for some shared configuration parameters for an extension. As you can see, I did not add the extension in the ru file so that require is pretty much irrelevant.

 

These lines are redundant: either this is a normal Ruby script and you call faye.listen(), or it's a Rackup script and you use the normal rackup API, not both.

faye.listen(9292)

run faye

How are you running this file on the command line?

bundle exec thin start -R ./faye.ru

I seem to be able to do the same thing by `bundle exec thin start -R ./faye.ru -p 9292`. This is probably more appropriate. Do you agree?

 

[Matt Smith]

On Thursday, May 10, 2012 2:38:45 AM UTC-7, Raphael Randschau wrote:

Luckily we were able to fix our problem using a combination of stunnel and haproxy.

The basic setup is this:

stunnel -> haproxy -> faye ( for ws and non-ws requests )

and 

stunnel -> haproxy -> nginx -> puma ( for rails and the likes )

faye runs using thin, and thin is configured without ssl since that is what stunnel is for.

Works like a charm! Hope you can fix your issues as well.

This worked great for me as well. I found that I had to use the http-sever-close option on the frontend and the http-pretend-keepalive on the faye backends to keep everything going to the right places at all times.

Thanks for all the input!

[James Coglan]

On 15 May 2012 18:04, Matt Smith <ma...@nearapogee.com> wrote:

How are you running this file on the command line?

bundle exec thin start -R ./faye.ru

I seem to be able to do the same thing by `bundle exec thin start -R ./faye.ru -p 9292`. This is probably more appropriate. Do you agree?

Yes, use rackup and specify the port in the command line. 

[James Coglan]

Glad it's fixed. Lots of people have used HAProxy and STunnel in front of Faye just fine. nginx/Apache tend to cause problems.