I redirected Sinatra output to log file. I was wondering how to skip all requests and write only errors Eg.
localhost - - [22/Dec/2010:15:47:32 AUSEDT] "GET /db/OMSGDV03/tlm HTTP/1.1" 200 93
- -> /A/B/C
shouldn't appear
You can turn off requests logging with:
set :logging, false
Related
When I am accessing:
get "/example/:id" do
...
slim :'example/show'
end
I am getting this error:
"GET /example/assets/app.css HTTP/1.1" 404
"GET /example/assets/app.js HTTP/1.1" 404
I am suspecting that :id can be a problem here, because
my assets setup works when I am accessing:
get "/example" do
...
slim :'example/index'
end
works:
"GET /assets/app.css HTTP/1.1" 304
"GET /assets/app.js HTTP/1.1" 200
My setup for sprockets:
class App < Sinatra::Base
set :environment, Sprockets::Environment.new
environment.append_path "assets/stylesheets"
environment.append_path "assets/javascripts"
environment.js_compressor = :uglify
environment.css_compressor = :scss
get "/assets/*" do
env["PATH_INFO"].sub!("/assets", "")
settings.environment.call(env)
end
...
end
My full repo but without last changes: https://github.com/aneta-bielska/home-for-paws-app
In your layout you have the following lines which define the links to your assets:
link rel="stylesheet" href="assets/app.css"
script src="assets/app.js"
Since the urls in these elements don’t start with a slash, the browser treats them as relative to the page where they appear. This means that when you visit /example the links go to /assets/app.cs and /assets/app.js. However when you go to e.g example/1 the links are treated as relative to the 1, so the browser tries to fetch /example/assets/app.cs (and similarly for app.js).
You need to make sure theses links are always treated as absolute. The simplest way would be to just add a / at the start:
link rel="stylesheet" href="/assets/app.css"
script src="/assets/app.js"
A more robust solution might be to use Sinatra’s url helper to ensure you always create the correct links, as it will take it account mounting the app at different paths on the server:
link rel="stylesheet" href=url("/assets/app.css")
script src=url("/assets/app.js")
For security reasons I don't wish to have Sinatra print every URL its requested in standard output, I've tried using set :logging, false as suggested in this answer using:
class SweetAppName< Sinatra::Base
set :show_exceptions, false
set :environment, :production
set :logging, false
However when I run the app using rackup and thin, I still see the request logged to the terminal:
127.0.0.1 - - [26/May/2015:09:32:34 -0700] "GET /not-a-real-url HTTP/1.0" 404 - 0.0452
How can I turn these off?
If you start your app with rackup, Rack will add some middleware, including logging. You can prevent this by using the quiet option (-q or --quiet) to rackup, i.e. from the command line:
$ rackup -q
You can include this option in your config.ru if you want, so you don’t have to remember typing it every time you start your app. The first line that starts with #\ is parsed as options, so you can have a config.ru like this:
#\ --quiet
# other middleware etc...
run SweetAppName
If you use the classic Sinatra app style you will need to add the set :logging, false line, otherwise Sinatra will add its own logging. With the modular style (like you are using in the question) this setting defaults to false so you shouldn’t need it.
I know different ways to make data persist between routes in Sinatra. I'm just trying to understand this more in a Ruby/Object-Oriented way.
My guess is: whenever you rackup a Sinatra app, you're instantiating a Sinatra::Application object. Is it that every time you call a get/post route method, you're creating a new Sinatra::Application so the instance variables will be different?
You're correct. Every time you open a new route, a new instance of your rack/sinatra app is re-instantiated.
You can check this out in a very simple way:
require 'sinatra/base'
class MyApp < Sinatra::Application
get '/' do
puts self.object_id
'Hello world!'
end
end
The output i get from this when opening the browser twice at "localhost:9292" is:
Thin web server (v1.6.2 codename Doc Brown)
Maximum connections set to 1024
Listening on 0.0.0.0:9292, CTRL+C to stop
70308503790680
127.0.0.1 - - [21/Jun/2014 16:10:21] "GET / HTTP/1.1" 200 12 0.0129
70308504166760
127.0.0.1 - - [21/Jun/2014 16:10:22] "GET / HTTP/1.1" 200 12 0.0016
Focus on the fourth and sixth line: you can see that the instances have different ids.
If you just output self, you can see that it's an instance of the MyApp class:
#<MyApp:0x007fbfea3a87c8>
127.0.0.1 - - [21/Jun/2014 16:19:54] "GET / HTTP/1.1" 200 12 0.0124
#<MyApp:0x007fbfea460198>
A while ago, I was fooling around with Node.js (I don't really remember what I did).
Now, whenever I launch Sinatra apps, I get this:
mba:sinatra chromium$ ruby basics.rb
[2011-12-16 18:38:23] INFO WEBrick 1.3.1
[2011-12-16 18:38:23] INFO ruby 1.9.2 (2011-07-09) [x86_64-darwin11.0.1]
== Sinatra/1.3.1 has taken the stage on 4567 for development with backup from WEBrick
[2011-12-16 18:38:23] INFO WEBrick::HTTPServer#start: pid=5708 port=4567
127.0.0.1 - - [16/Dec/2011 18:38:51] "GET / HTTP/1.1" 200 13 0.0072
localhost - - [16/Dec/2011:18:38:51 EST] "GET / HTTP/1.1" 200 13
- -> /
And for each HTTP request, WEBrick logs like 5 more lines.
How do I turn this off? I have no idea why this is happening, because I was doing this with Node.js, not WEBrick.
The line ruby basics.rb means that you are running Sinatra with Ruby, not Node.js.
If you want your Sinatra application launch a simple CGI daemon, not a complete HTTP server, you should use Sinatra::Base, not the normal Sinatra infrastructure. Applications based on Sinatra::Base do not launch WEBRick or any other server at startup and rely on an external HTTP server.
Have a look at the introduction to Sinatra::Base.
That is the normal logging output Sinatra creates.
Check the Readme if you want to turn logging off: https://github.com/sinatra/sinatra
I'm deploying a Sinatra app using passenger. The deployed app is working, but not entirely: some paths work fine, others simply render a blank page. I can't seem to find any major differences between the routes that work and the routes that don't, and I can't seem to track down any errors..
Handlers
I have defined the not_found and error handlers as follows:
not_found do
'404. Bummer!'
end
error do
'Nasty error: ' + env['sinatra.error'].name
end
These work fine on my local machine, both in development and production, but I never see these come up on the server.
Apache Logs
When I tail Apache's access.log and hit one of the broken paths, I see a 500:
helpers [27/Oct/2009:15:54:59 -0400] "GET /admin/member_photos/photos HTTP/1.1" 500 20 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3"
rack_hoptoad
I've also installed and configured rack_hoptoad middleware in my config.ru, but no exceptions are making it to hoptoad.
# Send exceptions to hoptoad
require 'rack_hoptoad'
use Rack::HoptoadNotifier, 'MY_API_KEY'
logging
I've set up logging like so..
set :raise_errors => true
set :logging, true
log = File.new("log/sinatra.log", "a+")
STDOUT.reopen(log)
STDERR.reopen(log)
require 'logger'
configure do
LOGGER = Logger.new("log/sinatra.log")
end
helpers do
def logger
LOGGER
end
end
This setup lets me call logger.info within my routes, which works locally and on the server for the working routes, but the broken paths don't get far enough to call logger.info.
What to do?
Any ideas as to how I can see what's causing the 500 errors? Thanks for any help!
I would try using the Rack::ShowExceptions middleware to try and trace out the problem. In your config.ru add these two lines before the run call:
require 'rubygems'
require 'your-app'
use Rack::ShowExceptions
run YourApp
That should catch and display the backtrace for any exceptions occurring in Rack or in your app. That should give you more details to work with, at least that would be the hope.
Maybe there's something wrong with your log setup?
Redirect STDERR when running the Sinatra server so you can read it. Like:
ruby myapp.rb -p 1234 > log/app.log 2>&1
Thanks for the responses, but I didn't end up needing to use them. I was originally deploying the app in a sub-URI configuration. When I deployed the app to it's own subdomain instead, the problems went away.
So.. I'm not really sure what the problem was, but getting rid of this line is my Apache configuration for the site is what resolved things:
Redirect permanent / https://www.example.org/admin/member_photos/