Smisk 1.1.6 released

2 views
Skip to first unread message

Rasmus Andersson

unread,
May 12, 2009, 11:54:38 AM5/12/09
to Smisk announcements
Smisk 1.1.6 has been released and is primarily a bug-fix release. It
also adds support for "Tolerant Applications" (RFC 2616 sect. 19.3)
Basically falling back on iso-8859-1 character encoding if needed
while decoding text from user input such as url-encoded PSTS and query
string. This feature can be disabled by setting the "tolerant"
property to "False" on an mvc.Application instance.


Changes (since 1.1.5):

* Handle requests with filename extensions which are actually not
filename extensions but rather format-less but leet.haxxor kinda dot
notation of the regular path component.

* Fixed 304 Not Modified response status not to set Location header
nor include a message-body.

* smisk.util.main.daemonize() does no longer call exit hooks while
detaching (calling os._exit instead of sys.exit in dead forks).

* Fixed bug in smisk.util.main.control_process_runloop() where signals
where not correctly forwarded to children.

* When core fail to decode text data from user input (form data and
query string) it will try to decode the text data using a fallback
charset, defined by SMISK_FALLBACK_CHARSET in config.h, which is set
to "ISO-8859-1" in accordance with HTTP 1.1 (RFC 2616), sect. 19.3
"Tolerant Applications".

* MVC applications respond with "400 Bad Request" when user input text
can not be decoded using app.charset (or iso-8859-1 if app.tolerant is
True).

* core.Application has a new boolean property "tolerant". When True
(default) user input will be processed in a tolerant manner. I.e. if a
query string encoded in iso-8859-1 is sent to an application with
app.charset of utf-8, the query string will still be decoded using the
HTTP 1.1 (RFC 2616) fallback encoding iso-8859-1, which is able do
decode any byte. If tolerant where False, a UnicodeDecodeError would
be raised.

* Static method core.URL.decompose_query() accepts a new boolean
argument "tolerant" which if True, charset argument is set and can
not be used to decode the first argument, causes decoding using the
iso-8859-1 charset.

* mvc.Response have two new members: The property "charsets" which is
a list of acceptable charsets. The method "accepts_charset" which
return True if the first argument is acceptable according to the
"charsets" list.

* MVC applications retain the content type used to find a valid
serializer or template and uses that content type in the response, if
appropriate. Previous behaviour was to send responses with the (per
serializer or template) canonical content type.


http://python-smisk.org/
Reply all
Reply to author
Forward
0 new messages