I'm having a rough time trying to get this simple streaming test to work using Sinatra and Rack.
In my stream.rb file, I have:
require 'sinatra'
require 'sinatra/streaming'
class StreamAPI < Sinatra::Base
helpers Sinatra::Streaming
get '/stream' do
stream do |out|
5.times do
out.puts "Hello!"
sleep 1
end
out.flush
end
end
run! if app_file == $0
end
And in my config.ru I have:
require 'rack'
require './stream.rb'
run StreamAPI
When I curl the url, I get "Hello!" 5 times, but all at once after 5 seconds. Looking at the headers I can see that Transfer-Encoding is set to Chunked. What I want is for the a "Hello!" to come through then another after a 1 second pause.
Edit: Along with the selected answer below, I also needed to add proxy_buffering off; to my NGINX configuration file.
This depends on which server you are using. From the Sinatra README:
Note that the streaming behavior, especially the number of concurrent requests, highly depends on the web server used to serve the application. Some servers, like WEBRick, might not even support streaming at all. If the server does not support streaming, the body will be sent all at once after the block passed to stream finishes executing.
It looks like you are using a server that doesn’t support streaming. If you switch to one that does (e.g. Thin or Puma) this should work.
Related
I'm testing a webscraper and I'd like to use Webmock to deliver fake websites for faster testing. When I mock a website, Ruby's native HTTP library works fine, but Capybara doesn't seem capable of receiving the mocked response. I know that webmock is stubbing low level HTTP requests, and I assume it matters which one capybara uses and which one webmock is configured to use. However, I need to know how Capybara makes HTTP requests and how I can configure webmock to stub that particular method set.
require 'capybara/poltergeist'
require 'webmock'
require 'pry'
include WebMock::API
WebMock.disable_net_connect!(allow_localhost:true)
Capybara.register_driver :poltergeist do |app|
Capybara::Poltergeist::Driver.new(app, js_errors: false)
end
# Configure Capybara to use Poltergeist as the driver
Capybara.default_driver = :poltergeist
Capybara.javascript_driver = :poltergeist
U = /google.com/
b = Capybara.current_session
stub_request(:any, U).
with(:headers => {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=0.3', 'User-Agent'=>'Ruby'}).
to_return(status:200, body:"abc", headers:{})
puts Net::HTTP.get(U,'/') #=> This returns "abc"
b.visit U
puts b.html #=> Throws error
The error I'm getting is as follows:
command': Request failed to reach server, check DNS and/or server status (Capybara::Poltergeist::StatusFailError)
I've tried using FakeWeb as well, but that simply was not capable of registering URIs. I'm open to using other APIs besides webmock if you think this is the wrong tool for the job.
Thanks in advance :)
Tom Walpole is correct. You can use WebMock to mock things your server is connecting to, but the browser makes its own connections and is unaffected by the changes you make to the server.
If you want to fake responses that the browser requests from other servers try something like Puffing Billy. Take a look at the Caching capability which can be setup to re-play results (much like VCR).
If you're working with something VERY simple you could try just loading the data you need with Capybara.string. But that's probably too limited for what you want.
Capybara doesn't make web requests, it tells the browser where to visit and the browser in turn makes the request. The way to do what you want is to use a proxy that can redirect specific browser requests to your own app
There is a newer and better way of doing this.
# spec/spec_helper.rb
RSpec.configure do |config|
config.before(:each) do |example|
if example.metadata[:type] == :feature
Capybara::Webmock.start
end
end
config.after(:suite) do
Capybara::Webmock.stop
end
end
Then use the capybara_webmock JavaScript driver:
# Use Chrome Driver
Capybara.javascript_driver = :capybara_webmock_chrome
https://github.com/hashrocket/capybara-webmock
I have phusion-passenger installed with apache on Ubuntu. In my config.ru, I have the following code:
require 'cgi'
$tpl = CGI.new['myvar'] + '.rb'
app = proc do |env|
[200, { "Content-Type" => "text/html" }, [$tpl]]
end
run app
So then when I go to my browser at http://localhost/?myvar=hello, I see the word hello printed out, which is fine. Then I change the url to http://localhost/?myvar=world, but the page still shows hello. Only after I reload apache will the page show world.
Before using phusion-passenger, I was using mod_ruby with apache. If I remember correctly, I didn't need to restart apache to get the CGI variable to print the updated value.
I'm not stuck on needing to use CGI. I just want to be able to grab query string parameters without having to reload apache each time.
I'm not using rails or Sinatra because i'm just trying to wrap my head around the Ruby language and what phusion-passenger with apache is all about.
IMO this behavior makes sense. Because $tpl is set only once when the file is loaded, what happens when the first request is served. After that - in following requests - only the proc is called, but that does not change $tpl anymore.
Instead of using plain CGI, I would do it with a very simple Rack app:
require 'rack'
require 'rack/server'
class Server
def self.call(env)
req = Rack::Request.new(env)
tpl = "#{req.params['myvar']}.rb"
[200, {}, [tpl]]
end
end
run Server
I'm building a Sinatra app that uses TweetStream (which listens for Tweets using EventMachine). I would also like the app to serve pages like a normal Sinatra app but it seems like Sinatra can't "listen" for page requests when it's "listening" for Tweets.
Is this something I can fix by using a different server or structuring my app in a different way? I've tried using WebBrick and Thin.
Here is basically what I'm doing:
class App < Sinatra::Base
# listening for tweets
#client = TweetStream::Client.new
#client.track(terms) do |status|
# do some stuff when I detect terms
end
get '/' do
"Here's some page content!"
end
end
You can mount Sinatra apps within eventmachine (providing you you a awebserver that supports EM i.e., Thin). You should then have full access to the EM reactor loop from your Sinatra app, as well as allowing any other EM plugins to run too.
The Sinatra recipes have a good example:
http://recipes.sinatrarb.com/p/embed/event-machine
here is a very stripped down version of the code:
require 'eventmachine'
require 'sinatra/base'
require 'thin'
def run(opts)
EM.run do
server = opts[:server] || 'thin'
host = opts[:host] || '0.0.0.0'
port = opts[:port] || '8181'
web_app = opts[:app]
dispatch = Rack::Builder.app do
map '/' do
run web_app
end
end
unless ['thin', 'hatetepe', 'goliath'].include? server
raise "Need an EM webserver, but #{server} isn't"
end
Rack::Server.start({
app: dispatch,
server: server,
Host: host,
Port: port
})
end
end
class HelloApp < Sinatra::Base
configure do
set :threaded, false
end
get '/hello' do
'Hello World'
end
get '/delayed-hello' do
EM.defer do
sleep 5
end
'I\'m doing work in the background, but I am still free to take requests'
end
end
run app: HelloApp.new
if you really want to use the tweets streaming feature then you need to run the streaming part as a separate process and write it's results say into a database, then read those records from your sinatra app.
that's how it works the twitter stream listener is a separate thing from your sinatra app and you need some sort of a queue to join them, say redis or db, or something like that.
ok so this is very strange (well is to me), everything in my master branch works fine, I then created a new branch called twitter to conduct some twitter feed implementation. I have done this and was working yesterday on my linux machine.. I have pulled the branch today in a windows environment but when i load the app i now get the regular Sinatra 404 Sinatra doesn’t know this ditty.
This is my profile.rb file
require 'bundler/setup'
Bundler.require(:default)
require 'rubygems'
require 'sinatra'
require './config/config.rb' if File.exists?('./config/config.rb')
require 'sinatra/jsonp'
require 'twitter'
require 'sinatra/static_assets'
class Profile < Sinatra::Base
helpers Sinatra::Jsonp
enable :json_pretty
register Sinatra::StaticAssets
##twitter_client = Twitter::Client.new(
:consumer_key => ENV["CONSUMER_KEY"],
:consumer_secret => ENV["CONSUMER_SECRET"],
:oauth_token => ENV["OAUTH_TOKEN"],
:oauth_token_secret => ENV["OAUTH_SECRET"],
)
get '/' do
erb :index
end
get '/feed' do
jsonp ##twitter_client.user_timeline('richl14').map(&:attrs)
end
end
Config.ru
require './profile'
run Profile
Does anyone have any ideas of what i need to be looking at to solve this? Can anyone speak from experience with this?
Thanks
When you use the classic Sinatra style you use require 'sinatra' and then add routes to the top level. These routes get added to the Sinatra::Application. When you directly run this file, e.g. with ruby my_app.rb, Sinatra runs a built in web server, which will serve the Sinatra::Application app.
When you use the modular style, you use require 'sinatra/base', and then add routes to your Sinatra::Base subclass. In this case directly executing the file doesn’t start the built in server.
In your case you are using the modular style, but have used require 'sinatra'. You create your Profile app, but when you run the file directly Sinatra launches the built in server and serves the Sinatra::Application app. Since you haven’t added any routes to this (they’ve all been added to Profile) it runs but all requests return 404.
One way to get your app to launch you is to use rackup. This will launch the Profile app that you have explicitly set in your config.ru. (Explicitly starting your webserver will also work, e.g. using thin start).
Another possibility would be to add a line like this to the end of your Profile class:
run! if app_file == $0
This tells Sinatra to start the build in server running the Profile app if the file is the same as the Ruby file being executed, in a similar way to how the classic style app is launched. If you use this method you should change require 'sinatra' to require 'sinatra/base' otherwise you will get two servers launched, one after the other (in fact you should probably make that change anyway).
See the Sinatra docs for more info about the difference between classic and modular style.
I am working on a website hosted on microsoft's office live service. It has a contact form enabling visitors to get in touch with the owner. I want to write a Ruby script that sits on a seperate sever and which the form will POST to. It will parse the form data and email the details to a preset address. The script should then redirect the browser to a confirmation page.
I have an ubuntu hardy machine running nginx and postfix. Ruby is installed and we shall see about using Thin and it's Rack functionality to handle the script. Now it's come to writing the script and i've drawn a blank.
It's been a long time and if i remember rightly the process is something like;
read HTTP header
parse parameters
send email
send redirect header
Broadly speaking, the question has been answered. Figuring out how to use the answer was more complicated than expected and I thought worth sharing.
First Steps:
I learnt rather abruptly that nginx doesn't directly support cgi scripts. You have to use some other process to run the script and get nginx to proxy requests over. If I was doing this in php (which in hind sight i think would have been a more natural choice) i could use something like php-fcgi and expect life would be pretty straight forward.
Ruby and fcgi felt pretty daunting. But if we are abandoning the ideal of loading these things at runtime then Rack is probably the most straight forward solution and Thin includes all we need. Learning how to make basic little apps with them has been profoundly beneficial to a relative Rails newcomer like me. The foundations of a Rails app can seem hidden for a long time and Rack has helped me lift the curtain that little bit further.
Nonetheless, following Yehuda's advice and looking up sinatra has been another surprise. I now have a basic sinatra app running in a Thin instance. It communicates with nginx over a unix socket in what i gather is the standard way. Sinatra enables a really elegant way to handle different requests and routes into the app. All you need is a get '/' {} to start handling requests to the virtual host. To add more (in a clean fashion) we just include a routes/script.rb into the main file.
# cgi-bin.rb
# main file loaded as a sinatra app
require 'sinatra'
# load cgi routes
require 'routes/default'
require 'routes/contact'
# 404 behaviour
not_found do
"Sorry, this CGI host does not recognize that request."
end
These route files will call on functionality stored in a separate library of classes:
# routes/contact.rb
# contact controller
require 'lib/contact/contactTarget'
require 'lib/contact/contactPost'
post '/contact/:target/?' do |target|
# the target for the message is taken from the URL
msg = ContactPost.new(request, target)
redirect msg.action, 302
end
The sheer horror of figuring out such a simple thing will stay with me for a while. I was expecting to calmly let nginx know that .rb files were to be executed and to just get on with it. Now that this little sinatra app is up and running, I'll be able to dive straight in if I want to add extra functionality in the future.
Implementation:
The ContactPost class handles the messaging aspect. All it needs to know are the parameters in the request and the target for the email. ContactPost::action kicks everything off and returns an address for the controller to redirect to.
There is a separate ContactTarget class that does some authentication to make sure the specified target accepts messages from the URL given in request.referrer. This is handled in ContactTarget::accept? as we can guess from the ContactPost::action method;
# lib/contact/contactPost.rb
class ContactPost
# ...
def action
return failed unless #target.accept? #request.referer
if send?
successful
else
failed
end
end
# ...
end
ContactPost::successful and ContactPost::failed each return a redirect address by combining paths supplied with the HTML form with the request.referer URI. All the behaviour is thus specified in the HTML form. Future websites that use this script just need to be listed in the user's own ~/cgi/contact.conf and they'll be away. This is because ContactTarget looks in /home/:target/cgi/contact.conf for the details. Maybe oneday this will be inappropriate, but for now it's just fine for my purposes.
The send method is simple enough, it creates an instance of a simple Email class and ships it out. The Email class is pretty much based on the standard usage example given in the Ruby net/smtp documentation;
# lib/email/email.rb
require 'net/smtp'
class Email
def initialize(from_alias, to, reply, subject, body)
#from_alias = from_alias
#from = "cgi_user#host.domain.com"
#to = to
#reply = reply
#subject = subject
#body = body
end
def send
Net::SMTP.start('localhost', 25) do |smtp|
smtp.send_message to_s, #from, #to
end
end
def to_s
<<END_OF_MESSAGE
From: #{#from_alias}
To: #{#to}
Reply-To: #{#from_alias}
Subject: #{#subject}
Date: #{DateTime::now().to_s}
#{#body}
END_OF_MESSAGE
end
end
All I need to do is rack up the application, let nginx know which socket to talk to and we're away.
Thank you everyone for your helpful pointers in the right direction! Long live sinatra!
It's all in the Net module, here's an example:
#net = Net::HTTP.new 'http://www.foo.com', 80
#params = {:name => 'doris', :email => 'doris#foo.com'}
# Create HTTP request
req = Net::HTTP::Post.new( 'script.cgi', {} )
req.set_form_data #params
# Send request
response = #net.start do |http|
http.read_timeout = 5600
http.request req
end
Probably the best way to do this would be to use an existing Ruby library like Sinatra:
require "rubygems"
require "sinatra"
get "/myurl" do
# params hash available here
# send email
end
You'll probably want to use MailFactory to send the actual email, but you definitely don't need to be mucking about with headers or parsing parameters.
CGI class of Ruby can be used for writing CGI scripts. Please check: http://www.ruby-doc.org/stdlib/libdoc/cgi/rdoc/index.html
By the way, there is no need to read the HTTP header. Parsing parametres will be easy using CGI class. Then, send the e-mail and redirect.