F.A.Q.¶
This is a loosely ordered collection of frequently asked questions, solutions for common problems, tips and other bits of knowledge.
General questions¶
Is bottle suitable for complex applications?¶
Bottle is first and foremost a micro framework. It is small, fast, easy to learn, stays out of your way and provides just enough functionality to get you started. This is perfect for prototyping, weekend projects, small applications, REST APIs or micro services, but you’ll have to get your hands dirty at some point. If there is no plugin available for the feature you need, you’ll have to write some glue code yourself. But that’s not as bad as it sounds. Bottle is small and straight forward. Unlike most other frameworks, you can actually find answers by reading its code. If you want to really understand and fully gasp your tech stack, then bottle is for you. But if you have tight deadlines and do not want to deal with any details, a more complete full-stack framework like django may be a better choice.
What about Flask?¶
Flask was heavily inspired by Bottle (*) and looks very similar on the surface, but took some very different design decisions. Most importantly, Flask is built on top of other libraries (e.g. Werkzeug, Jinja, Click and many more) which makes Flask itself small, but the actual code required to serve a single request is huge in comparison. I would not call it a micro framework at this point, but that’s just my personal opinion. If you prefer Flask, go for it.
Common errors and pitfalls¶
“Template Not Found” in mod_wsgi/mod_python¶
Bottle searches in ./
and ./views/
for templates. In a mod_python or mod_wsgi environment, the working directory (./
) depends on your Apache settings. You should add an absolute path to the template search path:
bottle.TEMPLATE_PATH.insert(0,'/absolut/path/to/templates/')
so bottle searches the right paths.
Dynamic Routes and Slashes¶
In dynamic route syntax, a placeholder token (<name>
) matches everything up to the next slash. This equals to [^/]+
in regular expression syntax. To accept slashes too, you have to add a custom regular pattern to the placeholder. An example: /images/<filepath:path>
would match /images/icons/error.png
but /images/<filename>
won’t.
Problems with reverse proxies¶
Redirects and url-building only works if bottle knows the public address and location of your application. If you run bottle locally behind a reverse proxy or load balancer, some information might get lost along the way. For example, the wsgi.url_scheme
value or the Host
header might reflect the local request by your proxy, not the real request by the client. Here is a small WSGI middleware snippet that helps to fix these values:
def fix_environ_middleware(app):
def fixed_app(environ, start_response):
environ['wsgi.url_scheme'] = 'https'
environ['HTTP_X_FORWARDED_HOST'] = 'example.com'
return app(environ, start_response)
return fixed_app
app = bottle.default_app()
app.wsgi = fix_environ_middleware(app.wsgi)
Recieps for common tasks¶
This is a collection of code snippets and examples for common use cases.
Keeping track of Sessions¶
There is no built-in support for sessions because there is no right way to do it (in a micro framework). Depending on requirements and environment you could use beaker middleware with a fitting backend or implement it yourself. Here is an example for beaker sessions with a file-based backend:
from bottle import Bottle, request
from beaker.middleware import SessionMiddleware
app = Bottle()
session_opts = {
'session.type': 'file',
'session.cookie_expires': 300,
'session.data_dir': './data',
'session.auto': True
}
app = SessionMiddleware(app, session_opts)
@app.route('/test')
def test():
s = request['beaker.session']
s['test'] = s.get('test',0) + 1
s.save()
return 'Test counter: %d' % s['test']
app.run()
WARNING: Beaker’s SessionMiddleware is not thread safe. If two concurrent requests modify the same session at the same time, one of the updates might get lost. For this reason, sessions should only be populated once and treated as a read-only store after that. If you find yourself updating sessions regularly, and don’t want to risk losing any updates, think about using a real database instead or seek alternative session middleware libraries.
Debugging with Style: Debugging Middleware¶
Bottle catches all Exceptions raised in your app code to prevent your WSGI server from crashing. If the built-in debug()
mode is not enough and you need exceptions to propagate to a debugging middleware, you can turn off this behaviour:
import bottle
app = bottle.Bottle()
app.catchall = False # Now most exceptions are re-raised within bottle.
myapp = DebuggingMiddleware(app) #Replace this with a middleware of your choice (see below)
bottle.run(app=myapp)
Now, bottle only catches its own exceptions (HTTPError
, HTTPResponse
and BottleException
) and your middleware can handle the rest.
The werkzeug and paste libraries both ship with very powerful debugging WSGI middleware. Look at werkzeug.debug.DebuggedApplication
for werkzeug and paste.evalexception.middleware.EvalException
for paste. They both allow you do inspect the stack and even execute python code within the stack context, so do not use these in production!
Unit-Testing Bottle Applications¶
Unit-testing is usually performed against methods defined in your web application without running a WSGI environment.
A simple example:
import bottle
@bottle.route('/')
def index():
return 'Hi!'
if __name__ == '__main__':
bottle.run()
Test script:
import mywebapp
def test_webapp_index():
assert mywebapp.index() == 'Hi!'
In the example the Bottle route() method is never executed - only index() is tested.
If the code being tested requires access to bottle.request
you can mock it using Boddle:
import bottle
@bottle.route('/')
def index():
return 'Hi %s!' % bottle.request.params['name']
Test script:
import mywebapp
from boddle import boddle
def test_webapp_index():
with boddle(params={'name':'Derek'}):
assert mywebapp.index() == 'Hi Derek!'
Functional Testing Bottle Applications¶
Any HTTP-based testing system can be used with a running WSGI server, but some testing frameworks work more intimately with WSGI, and provide the ability the call WSGI applications in a controlled environment, with tracebacks and full use of debugging tools.
Example using WebTest:
from webtest import TestApp
import myapp
def test_functional_login_logout():
app = TestApp(myapp.app)
app.post('/login', {'user': 'foo', 'pass': 'bar'}) # log in and get a cookie
assert app.get('/admin').status == '200 OK' # fetch a page successfully
assert app.get('/logout').status_code == 200 # log out
app.reset() # drop the cookie
# fetch the same page, unsuccessfully
assert app.get('/admin', expect_errors=True).status == '401 Unauthorized'
Ignore trailing slashes¶
For Bottle, /example
and /example/
are two different routes [1]. To treat both URLs the same you can add two @route
decorators:
@route('/test')
@route('/test/')
def test(): return 'Slash? no?'
add a WSGI middleware that strips trailing slashes from all URLs:
class StripPathMiddleware(object):
def __init__(self, app):
self.app = app
def __call__(self, e, h):
e['PATH_INFO'] = e['PATH_INFO'].rstrip('/')
return self.app(e,h)
app = bottle.app()
myapp = StripPathMiddleware(app)
bottle.run(app=myapp)
or add a before_request
hook to strip the trailing slashes:
@hook('before_request')
def strip_path():
request['PATH_INFO'] = request['PATH_INFO'].rstrip('/')
Footnotes
Keep-alive requests¶
Note
For a more detailed explanation, see Asynchronous Applications.
Several “push” mechanisms like XHR multipart need the ability to write response data without closing the connection in conjunction with the response header “Connection: keep-alive”. WSGI does not easily lend itself to this behavior, but it is still possible to do so in Bottle by using the gevent async framework. Here is a sample that works with either the gevent HTTP server or the paste HTTP server (it may work with others, but I have not tried). Just change server='gevent'
to server='paste'
to use the paste server:
from gevent import monkey; monkey.patch_all()
import gevent
from bottle import route, run
@route('/stream')
def stream():
yield 'START'
gevent.sleep(3)
yield 'MIDDLE'
gevent.sleep(5)
yield 'END'
run(host='0.0.0.0', port=8080, server='gevent')
If you browse to http://localhost:8080/stream
, you should see ‘START’, ‘MIDDLE’, and ‘END’ show up one at a time (rather than waiting 8 seconds to see them all at once).
Gzip Compression in Bottle¶
A common feature request is for Bottle to support Gzip compression, which speeds up sites by compressing static resources (like CSS and JS files) during a request.
Supporting Gzip compression is not a straightforward proposition, due to a number of corner cases that crop up frequently. A proper Gzip implementation must:
Compress on the fly and be fast doing so.
Do not compress for browsers that don’t support it.
Do not compress files that are compressed already (images, videos).
Do not compress dynamic files.
Support two differed compression algorithms (gzip and deflate).
Cache compressed files that don’t change often.
De-validate the cache if one of the files changed anyway.
Make sure the cache does not get to big.
Do not cache small files because a disk seek would take longer than on-the-fly compression.
Because of these requirements, it is the recommendation of the Bottle project that Gzip compression is best handled by the WSGI server Bottle runs on top of. WSGI servers and reverse proxies often provide built-in features that allow transparent compression without changing the application itself.
Using hooks to handle CORS¶
Hooks are useful to unconditionally do something before or after each request. For example, if you want to allow Cross-Origin requests for your entire application, instead of writing a plugin you can use hooks to add the appropiate headers:
from bottle import hook, response, HTTPResponse
cors_headers = {
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
# 'Access-Control-Allow-Headers': 'X-Token, ...',
# 'Access-Control-Expose-Headers': 'X-My-Custom-Header, ...',
# 'Access-Control-Max-Age': '86400',
# 'Access-Control-Allow-Credentials': 'true',
}
@hook('before_request')
def handle_options():
if request.method == 'OPTIONS':
# Bypass request routing and immediately return a response
raise HTTPResponse(headers=cors_headers)
@hook('after_request')
def enable_cors():
for key, value in cors_headers.items():
response.set_header(key, value)
Using Bottle with Heroku¶
Heroku, a popular cloud application platform now provides support for running Python applications on their infrastructure.
This recipe is based upon the Heroku Quickstart, with Bottle specific code replacing the Write Your App section of the Getting Started with Python on Heroku/Cedar guide:
import os
from bottle import route, run
@route("/")
def hello_world():
return "Hello World!"
run(host="0.0.0.0", port=int(os.environ.get("PORT", 5000)))
Heroku’s app stack passes the port that the application needs to listen on for requests, using the os.environ dictionary.