Profile cover photo
Profile photo
Bottle
360 followers -
Bottle is a fast, simple and lightweight WSGI micro web-framework for Python.
Bottle is a fast, simple and lightweight WSGI micro web-framework for Python.

360 followers
About
Communities and Collections
Posts

Post has attachment
Add a comment...

Post has attachment
One of the most annoying limitations you may encounter in bottle when building bigger applications is the way templates are searched on the file system. Here is a workaround: http://blog.bottlepy.org/2012/07/20/template-search-path-workaround.html
Add a comment...

Post has attachment
Bottle just got a /real/ development blog. With code-highlighting, RSS feeds, git-managed content and more nice stuff. Head over to http://blog.bottlepy.org/ and tell us what you think (on twitter or via disqus comments). And don't forget to tell your RSS-reader about it! Never miss a release again :)

Want to contribute? Found a typo? The new blog is fork-able on github: https://github.com/defnull/blog.bottlepy.org
Add a comment...

Looks like the next release (0.11) will break backwards compatibility in some edge cases. I am working on a patch that affects routes that stream content (yield) and access request/response after the first chunk of data is returned.

Details:
Accessing the thread-local request/response objects after yielding a chunk of data works most of the time, but is a bad idea anyway. The request context (the state of request/response) is undefined at that point. As soon as the route callback yields data, Bottle hands the response over to the WSGI server and is no longer in control. The server might start a new thread to send the stream to a client and thus break the thread-local request/response proxies. That'd be a very subtle bug and hard-to-debug scenario.

It worked until now because bottle does not delete the context, it just overwrites it as soon as a new request arrives.

Whats new?
The thread-local request/response proxies will raise a RuntimeError() if they are accessed outside of a request-cycle (before a request or after the first chunk of data is returned).

How to upgrade?
There are two new ways to get a real, local, persistent instance to the current request object: bottle.get_current_request() and bottle.request.get_current(). The object returned by these functions survives as long as you keep the reference around.

 @route('/stream')
  def stream():
    # Get a local reference BEFORE returning data
    local_request = request.get_current()
    # Now we can use that instead of the global proxy
    for i in range(100):
      yield 'Hello %s!' % local_request.forms.name


As said above, the change is not committed yet. I am still experimenting. Just wanted to write it down to clear my head. The matter is even more complicated than explained here.
Add a comment...

Post has attachment
Bugfix Release 0.10.11

The Python 3.x unicode problem was more complex than I thought. I had to re-implement urllib.parse_qsl to work around an encoding problem in 3.1 and change the way bottle handles query-strings in subtle ways. Again, please read this before upgrading: http://bottlepy.org/docs/dev/tutorial.html#unicode-issues
Add a comment...

Bugfix Release 0.10.10

Python 3.2+ cgi.FieldStorage() defaults to utf8 when decoding form values. That confused bottle.FormsDict() because WSGI strings "must contain only code points representable in ISO-8859-1 encoding". Now bottle forces cgi.FieldStorage() to use ISO-8859-1 instead and re-encodes form-values on-demand with the user-specified input encoding a intended.

If you are getting encoding errors after this fix, note that the form-dictionaries contain unaltered strings as sent by the client. Only the .getunicode() method and the attribute access methods honor a user-defined input encoding.

EDIT: Here is how it works now: http://bottlepy.org/docs/dev/tutorial.html#unicode-issues
Add a comment...

Post has attachment
Andrea Belvedere found a bug in SimpleTALTemplates that went unnoticed for months. Conclusion: Nobody actually uses Bottle+TAL.

Perhaps it is a good time to remove SimpleTALTemplate support instead of fixing it. Or move it to a plugin.

Here is the deal: The TAL template adapter needs a maintainer or support will be removed within the next two releases.

https://github.com/defnull/bottle/issues/322
Add a comment...

Post has attachment
This might be useful for Plugin developers:
https://github.com/defnull/bottle/commit/a21d71694fdea222844dba5076efad3726ccdb68

To sum it up: You can now add custom attributes or properties to the bottle.request object. These are stored in the environ dictionary ('bottle.request.ext.*' namespace) which has some advantages over traditional instance attributes:

- User defined attributes don't leak into other requests.
- They are garbage-collected soon after the request is over.
- You can add or read these values from low-level middleware or via plugins.

Something like bottle.request.db or bottle.request.session is now feasible. You can add methods, too (using types.MethodType(func, bottle.request)).
Add a comment...

Post has attachment
My server harddisk died today. Until I get a new one installed, you can use the mirror at http://readthedocs.org/docs/bottle/en/latest/
Add a comment...

I just released 0.10.7 (security release). It fixes a possible DoS vulnerability that is caused by hash collisions in CPython dicts.

This bug is not specific to bottle. I you are using other frameworks, check for updates there too.

Details: https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web-application-plattforms-hashdos/

"If the language does not provide a randomized hash function or the application server does not recognize attacks using multi-collisions, an attacker can degenerate the hash table by sending lots of colliding keys. The algorithmic complexity of inserting n elements into the table then goes to O(n**2), making it possible to exhaust hours of CPU time using a single HTTP request."

This workaround limits the number of GET, POST and cookie parameters to a reasonable number of 100 key/value pairs per request, reducing the effectiveness of attacks. Normal web applications should not need to process more than 100 parameters per request, but this limit can be changed by setting Request.MAX_PARAMS to a different value.

Some more links:
http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html
http://www.nruns.com/_downloads/advisory28122011.pdf
https://github.com/defnull/bottle/commit/6946695b69f5493fb063c351400ff759323a31aa
Add a comment...
Wait while more posts are being loaded