Allow network access to Sinatra server running on Rack?

80 views
Skip to first unread message

jtin...@soasta.com

unread,
Sep 3, 2015, 8:10:43 AM9/3/15
to Rack Development
Hi all,

Sinatra supports access over the network by setting the bind setting to '0.0.0.0' - I can't seem to find any docs on how this is achieved when running Sinatra via Rack::Cascade. Anyone have any Ideas??

Also, finding it hard to find docs on how to pass Rackup --options into the Sinatra app running in Rack::Cascade.

Thanks - any help much appreciated!

James


Steve Fazekas

unread,
Sep 3, 2015, 9:09:35 AM9/3/15
to rack-...@googlegroups.com
James,

I think I have that config set up for my  own use and when I get into work later I'll send you what I have this afternoon.  If you think everything is set correctly try setting a different port. 

Steve Fazekas
--

---
You received this message because you are subscribed to the Google Groups "Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jtin...@soasta.com

unread,
Sep 3, 2015, 12:11:42 PM9/3/15
to Rack Development
Hi Steve,

Thanks. I am passing in the port setting when starting rack from the command line like so :$ rackup --server thin --host localhost --port 4567

I also pass in options via the --options flag but can't seem to find any documentation on how to access these options anywhere!

James

jtin...@soasta.com

unread,
Sep 3, 2015, 12:15:18 PM9/3/15
to Rack Development
Aha - it was just a matter of setting the host to 0.0.0.0 in the command options like so :$ rackup --server thin --host 0.0.0.0 --port 4567

Still no idea how to access the options though :(

James Tucker

unread,
Sep 7, 2015, 11:50:32 AM9/7/15
to Rack Development

Those are really server options. Rackup isn't really a framework. People often want to extend it for this purpose, but isnt designed in that way really.

What you could do would be to write your own binary, using rack::server and then grab options from there, but in that case you'd really be better off implementing options yourself so that you have more control and aren't reliant on APIs that no one really uses (and thus may be subject to change).

Racks server infrastructure has always been designed to be used programmatically for this reason.

Reply all
Reply to author
Forward
0 new messages