I'm trying to test if a uri is valid (e.g. actually has content, not testing if it is well formed here) using ruby code, and I can open a uri using open(uri). But in my case, the uri is a link to a file to be downloaded and I don't want to have to download the whole file just to verify that there is content there.
Is there another solution for this?
Try this
require 'net/http'
u = URI.parse('http://www.example.com/')
status = Net::HTTP.start(u.host, u.port).head(u.request_uri).code
# status is HTTP status code
You'll need to use rescue to catch exception in case domain resolution fails.
Related
I try to proxy traffic of a ruby application over a SOCKS proxy using ruby 2.0 and SOCKSify 1.5.0.
require 'socksify/http'
uri = URI.parse("www.example.org")
proxy_addr = "127.0.0.1"
proxy_port = 14000
puts Net::HTTP.SOCKSProxy(proxy_addr, proxy_port).get(uri)
This is the minimal working example. Obviously it doesn't work but I think it should. I receive no error messages executing the file, it doesn't stop so I have to abort it manually. I have tried the solution after I found it in this answer (the code in that answer is different, but as mentioned above I first adapted it to my match my existing non-proxy-code and afterwards reduced it)
The proxies work, I tested both tor and ssh -D connection on my own webserver and other websites.
As rubyforge seems to be no longer existing, I can't access the SOCKSify documentation on it. I think the version might be outdated, does not work with ruby 2.0 or something like that.
What am I doing wrong here? Or is there an alternative to SOCKSify?
Checking the documentation for Net::HTTP#Proxies gives an example we can base our code on. Also note the addition of the .body method, also found in the documentation.
Try this code:
require 'socksify/http'
uri = URI.parse('http://www.example.org/')
proxy_addr = '127.0.0.1'
proxy_port = 1400
Net::HTTP.SOCKSProxy(proxy_addr, proxy_port).start(uri.host, uri.port) do |http|
puts http.get(uri.path).body
end
I am attempting to write a Twilio script to do voice broadcasting without rails - I would like to be able to run the script straight from my terminal.
I have a very simple script, straight from the twilio-rb gem docs:
# This should be in an initializer or similar
Twilio::Config.setup \
:account_sid => account,
:auth_token => token
Twilio::Call.create :to => '+1234567890', :from => '+0987654321',
:url => xml_file
xml_file is a xml file on my local machine, but it throws this error:
Error #21205: Url is not a valid url
How can I write the above script to operate off of a local xml file? The end goal is strictly to make a phone call, play an audio message, gather a button press and do an action based on the number received. The Twiml XML file should do that for me, if I can get it to work.
EDIT:
When using the dropbox share link, I get this error within the Twilio interface:
'Twilio is unable to process the Content-Type of the provided URL. Please see the Twilio Markup XML Documentation for more information on valid Content-Types.
You must return a Content-Type for all requests. Requests without a Content-Type will appear in the Debugger as a 502 Bad Gateway error.
Having a phone number, outgoing call request or action attribute refer to a non XML or audio resource.
Having a Play verb attempt to play non-audio content, such as XML or text.
Verify that that your web server is returning a Content-Type and it is the expected value
Make sure the URL noted refers to a valid resource'
To make sure, I copied an example I know will work into my XML file:
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Say voice="man">Hey man! Listen to this!</Say>
<Play>http://foo.com/cowbell.mp3</Play>
<Say voice="man">What did you think of that?!</Say>
<Record action="http://foo.com/handleRecording.php" method="GET" maxLength="20" finishOnKey="*"/>
<Gather action="/process_gather.php" method="GET">
<Say>Now hit some buttons!</Say>
</Gather>
<Say voice="man">Awesome! Thanks!</Say>
<Hangup/>
</Response>
Two ideas to try:
(1) If the file is read locally and sent to the Twilio server, try:
:url => 'file:///path/file.xml'
where
host in //host/ is omitted, yielding three slashes in a row.
path is the full filesystem path to your XML file.
file.xml is the name of your XML file.
(2) If the file must be publicly readable by the Twilio server, try placing it in the cloud somewhere (such as Dropbox) and using the public URL to it there.
I use OpenURI library.
object = open("http://example.com")
If http://example.com server code response is equals to 200 my program acts as I expected.
But if http://example.com server response code is equals to 400 (or other) then script aborts with OpenURI::HTTPError: 404 Not Found.
I can avoid this if I use 'begin-rescue' construction and handle 'HTTPError exception'.
Is this a correct way?
Should I use Net/Http library instead of OpenURI to handle all cases?
Rescuing the OpenURI::HTTPError is perfectly reasonable. See this related answer: https://stackoverflow.com/a/7495389/289274
But if you would rather not deal with exception handling, here's how you can do it with Net::HTTP:
https://stackoverflow.com/a/2797443/289274
I'm getting this error:
WSDL::XMLSchema::Parser::UnknownElementError
unknown element: {}HTML
at 'new'
when I consume webservices using Ruby. Here is the code snippet:
require 'soap/wsdlDriver'
wsdl = url
driver = SOAP::WSDLDriverFactory.new(wsdl).create_rpc_driver
driver.options["protocol.http.basic_auth"] << [url, user_name, password]
the url points to a well-formed xml.
Any solutions?
Can you share the wsdl file? Maybe that would help us answering it better.
In any case, I'd suggest generating the Driver classes first using wsdl2ruby. And then loding them in your Ruby file (through require). Examples (from the man pages):
# For server side:
$ wsdl2ruby.rb --wsdl myapp.wsdl --type server
# For client side:
$ wsdl2ruby.rb --wsdl myapp.wsdl --type client
If you load the URL in a web browser, does it get redirected to a different location?
In my experience, one reason the error "unknown element: {}HTML" comes up is the WSDL parser is trying to parse the HTML portion of the HTTP redirect and failing to do so. Therefore, you should deal with the redirect yourself (either in code or manually) and give the WSDL driver the final URL.
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.