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:

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:

importbottleapp=bottle.app()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)

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 them in production.

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. Testing tools for WSGI is a good starting point.

fromwebtestimportTestAppimportmywebappdeftest_functional_login_logout():app=TestApp(mywebapp.app)app.post('/login',{'user':'foo','pass':'bar'})# log in and get a cookieassertapp.get('/admin').status=='200 OK'# fetch a page successfullyapp.get('/logout')# log outapp.reset()# drop the cookie# fetch the same page, unsuccessfullyassertapp.get('/admin').status=='401 Unauthorized'

This is not the recommend way (you should use a middleware in front of bottle to do this) but you can call other WSGI applications from within your bottle app and let bottle act as a pseudo-middleware. Here is an example:

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:

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 such as cherrypy provide a GzipFilter middleware that can be used to accomplish this.