Smisk 1.1.6

Because Smisk aims to be a platform for web service development, rather than just HTML web sites, the idea of a MVC takes a step further in terms of pragmatism and simplicity.
Smisk is capable of understanding and answering in many different languages, or formats, often removing the need for custom Views (templates).
Smisk is comprised of two major layers:
- Core layer: Includes basic functionality, like request parsing, I/O, session and response handling. The smisk core is native machine code for maximum performance. Some applications can be written directly against the core, as it provides all means necessary for small processes.
- MVC layer: This layer implements the classic Model-View-Controller paradigm. And here is where the similarities with other frameworks end. Smisk MVC is strictly REST-based, and can handle the presentation automatically. (Yup, thats the "V" in MVC).

Enhancements
- 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.