Uwsgi

Bugfixes
********

- fixed teajs engine build

- fixed offloading status code (set to 202 when a request is offloaded)

- execute cron tasks within 60 second resolution, instead of 61 seconds

- fixed websocket proxy

- check for python3 unicode encoding (instead of crashing...)

- fixed ipcsem removal on reload

- fixed kqueue timer on OpenBSD, NetBSD and DragonFlyBSD

- fixed/reimplemented perl uwsgi::register_rpc

- fixed fd leak on sendfile() error

- fixed Content-Length when gzip file variant is used

- allows non-request plugins to register rpc functions

- more robust error checking for cgroups

- honour SCRIPT_NAME the in the PSGI plugin when multiple perl apps are mounted


New features
************


Legion cron
^^^^^^^^^^^

A common needs when multiple instances of an application are running, is to force only one
of them to run cron tasks. The new --legion-cron uses :doc:`Legion` to accomplish that:

.. code-block:: ini

[uwsgi]
; use the new legion-mcast shortcut (with a valor 90)
legion-mcast = mylegion 225.1.1.1:9191 90 bf-cbc:mysecret
; run the script only if the instance is the lord of the legion "mylegion"
legion-cron = mylegion -1 -1 -1 -1 -1 my_script.sh


Curl cron
^^^^^^^^^

The curl_cron plugin has been added allowing the cron subsystem to call urls (via libcurl) instead of unix commands:

.. code-block:: ini

[uwsgi]
; call http://uwsgi.it every minute
curl-cron = -1 -1 -1 -1 -1 http://uwsgi.it/

The output of the request is reported in the log

The UWSGI_EMBED_PLUGINS build variable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ou can now embed plugins on the fly during the build phase. Check this example:

.. code-block:: sh

UWSGI_EMBED_PLUGINS=gridfs,rack UWSGI_PROFILE=psgi make

this will build a monolithic binary with the default profile for psgi + the gridfs and the rack plugins (both embedded in the binary)


Gzip caching
^^^^^^^^^^^^

The cachestore routing function can now directly store items in gzip format.

Check the CachingCookbook: https://uwsgi-docs.readthedocs.io/en/latest/tutorials/CachingCookbook.html

--skip-atexit
^^^^^^^^^^^^^

A bug in the mongodb client library could cause a crash of the uWSGI server during shutdown/reload. This option
avoid calling atexit() hooks. If you are building a :doc:`GridFS` infrastructure you may want to use this option while the MongoDB guys solve the issue.

proxyhttp and proxyuwsgi
^^^^^^^^^^^^^^^^^^^^^^^^

The http and uwsgi routing instructions are now more smart. You can cache their output and get the right status code in the logs.

This requires you to NOT use offloading. If offloading is in place and do not want to use it for this two router use the proxy-prefixed variant
that will skip offloading.

You can now make cool things like:

.. code-block:: ini

[uwsgi]
socket = 127.0.0.1:3031
; create a cache of 100 items
cache = 100
; check if a cached value is available
route-run = cache:key=${REQUEST_URI}
; proxy all request to http://unbit.it
route-run = http:81.174.68.52:80,unbit.it
; and cache them for 5 minutes
route-run = cachestore:key=${REQUEST_URI},expires=300

The transformation api
^^^^^^^^^^^^^^^^^^^^^^

A generic api for manipulating the response has been added (cachestore uses it)

check :doc:`Transformations`

--alarm-fd
^^^^^^^^^^

We are improving :doc:`AlarmSubsystem` to be less-dependent on loglines. You can now trigger alarms when an fd is ready for read.

This is really useful for integration with the Linux eventfd() facility.

For example you can monitor (and throw an alarm) when your cgroup is running the OOM-Killer:

.. code-block:: ini

[uwsgi]
; define an 'outofmemory' alarm that simply print the alarm in the logs
alarm = outofmemory log:
; raise the alarm (with the specified message) when fd is ready (this is an eventfd se we read 8 bytes from the fd)
alarm-fd = outofmemory $(CGROUP_OOM_FD):8 OUT OF MEMORY !!!

in this example CGROUP_OOM_FD is an environment variable mapping to the number of an eventfd() filedescriptor inherited from some kind
of startup script. Maybe (in the near future) we could be able to directly define this kind of monitor directly in uWSGI.

More information on the eventfd() + cgroup integration are here: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

an example perl startup script:

.. code-block:: pl

use Linux::FD;
use POSIX;

my $foo = Linux::FD::Event->new(0);
open OOM,'/sys/fs/cgroup/uwsgi/memory.oom_control';
# we dup() the file as Linux::FD::Event set the CLOSE_ON_EXEC bit (why ???)
$ENV{'CGROUP_OOM_FD'} = dup(fileno($foo)).'';

open CONTROL,'>/sys/fs/cgroup/uwsgi/cgroup.event_control';
print CONTROL fileno($foo).' '.fileno(OOM)."\n";
close CONTROL;

exec 'uwsgi','mem.ini';

The spooler server plugin and the cheaper busyness algorithm compiled in by default
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In extremely high-loaded scenario the busyness cheaper algorithm (by Łukasz Mierzwa) has been a real
silver bullet in the past months allowing adaptive process spawning to be based on real usage time taking in account
performance and response time. For this reason the plugin is now builtin by default.

In addition to this the remote spooler plugin (allowing external process to enqueue jobs) has been added too in the default build profile.


Availability
************

uWSGI 1.9.7 will be available since 20130422 at this url:

https://projects.unbit.it/downloads/uwsgi-1.9.7.tar.gz

Changelog 20130409

Bugfixes
********

* workaround for building the python plugin with gcc 4.8

Sorry, this is not a real bugfix, but making a release without bugfixes seems wrong...

New Features
************

Sqlite and LDAP pluginization
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Storing configurations in sqlite databases or LDAP tree is a pretty "uncommon" way to configure uWSGI
instances. For such a reason they have been moved to dedicated plugins.

If you store config in a sqlite database, just add --plugin sqlite3. For LDAP, just add --plugin ldap:

.. code-block:: sh

uwsgi --plugin sqlite --sqlite config.db

Configuring dynamic apps with internal routing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

'Til now, you need to configure your webserver to load apps dinamically.

Three new instructions have been added to load application on demand.

Check the example:

.. code-block:: ini

[uwsgi]

http-socket = :9090

route = ^/foo chdir:/tmp
route = ^/foo log:SCRIPT_NAME=${SCRIPT_NAME}
route = ^/foo log:URI=${REQUEST_URI}
route = ^/foo sethome:/var/uwsgi/venv001
route = ^/foo setfile:/var/uwsgi/app001.py
route = ^/foo break:

route = ^/bar chdir:/var
route = ^/bar addvar:SCRIPT_NAME=/bar
route = ^/bar sethome:/var/uwsgi/venv002
route = ^/bar setfile:/var/uwsgi/app002.py
route = ^/bar break:

as you can see, rewriting SCRIPT_NAME is now very easy. The sethome instruction is currently available only for python application
(it means 'virtualenv')

Carbon avg computation (Author: Łukasz Mierzwa)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You can now configure how the carbon plugin send the response average when no requests have been managed.

You have three ways:

--carbon-idle-avg none - don't push any avg_rt value if no requests were made

--carbon-idle-avg last - use last computed avg_rt value (default)

--carbon-idle-avg zero - push 0 if no requests were made



Numeric checks for the internal routing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

New check are available:

ishigher or '>'

islower or '<'

ishigherequal or '>='

islowerequal or '<='

Example:

.. code-block:: ini

[uwsgi]
route-if = ishigher:${CONTENT_LENGTH};1000 break:403 Forbidden


Math and time for the internal routing subsystem
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you build uWSGI with matheval support (matheval-dev on debian/ubuntu) you will get
math support in your routing system via the 'math' routing var.

The 'time' routing var has been added currently exporting only the 'unix' field returning the epoch.

Check this crazy example:

.. code-block:: ini

[uwsgi]
http-socket = :9090
route-run = addvar:TEMPO=${time[unix]}
route-run = log:inizio = ${TEMPO}
route-run = addvar:TEMPO=${math[TEMPO+1]}
route-run = log:tempo = ${TEMPO}


As you can see the routing subsystem can store values in request variables (here we create a 'TEMPO' var, and you will be able to access it even in your app request vars)

The 'math' operations can reference request vars

Check the matheval docs for the supported operations: http://matheval.sourceforge.net/docs/index.htm

Added non-standard seek() and tell() to wsgi.input (post-buffering required)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

While testing the 'smart mode' of the 'Klaus' project (https://github.com/jonashaag/klaus) we noticed it was violating
the WSGI standard calling seek() and tell() when in smart mode.

We have added support for both methods when post-buffering is enabled.

REMEMBER: they violate the WSGI standard, so try to avoid them (if you can). There are better ways to accomplish that.

Pyshell improvements, AKA Welcome IPython (Idea: C Anthony Risinger)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You can invoke the ipython shell instead of the default one when using --pyshell:

.. code-block:: sh

uwsgi -s :3031 --pyshell="from IPython import embed; embed()"

Obviously you can pass whatever code to --pyshell

The 'rpcraw' routing instruction
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Another powerful and extremely dangerous routing action. It will call a rpc function
sending its return value directly to the client (without further processing).

Empty return values means "go to the next routing rule".

Return values must be valid HTTP:

.. code-block:: js

uwsgi.register_rpc('myrules', function(uri) {
if (uri == '/foo') {
return "HTTP/1.0 200 OK\r\nContent-Type: text/plain\r\nServer: uWSGI\r\nFoo: bar\r\n\r\nCiao Ciao";
}
return "";
});

.. code-block:: ini

[uwsgi]
plugin = v8
v8-load = rules.js
route = ^/foo rpcraw:myrules ${REQUEST_URI}


Preliminary support for the HTTP Range header
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The range request header allows requesting only part of a resource (like a limited set of bytes of a static file).

The system can be used when serving static files, but it is disabled by default. Just add --honour-range to enable it.

In the future it will be used for file wrappers (like wsgi.file_wrapper) and for :doc:`GridFS` (this is the reason for not enabling it by default
as you could have already implemented range management in your app)


The 'lord' routing condition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We are working hard on making a truly amazing cluster subsystem using :doc:`Legion`

You can now execute internal routing rules when an instance is a lord:

.. code-block:: ini

[uwsgi]
...
route-if = lord:mylegion log:I AM THE LORD !!!

the "I AM THE LORD !!!" logline will be printed only when the instance is a lord of the legion 'mylegion'

GridFS authentication
^^^^^^^^^^^^^^^^^^^^^

You can now connect to authenticated MongoDB servers when using :doc:`GridFS`

Just add the username and password parameters to the mount definition

The --for-times config logic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You can use --for-times for running uWSGI options the specified number of times:

.. code-block:: ini

[uwsgi]
for-times = 8
mule = true
endfor =

this will spawn 8 mules

The 'uwsgi' routing var
^^^^^^^^^^^^^^^^^^^^^^^

Accessing uWSGI internal parameters when defining routing rules could be handy. The 'uwsgi' routing var
is the container for such vars.

Currently it exports 'wid' (the id of the worker running the rule) and 'pid' (the pid of the worker running the rule)

.. code-block:: ini

[uwsgi]
master = true
processes = 4
; stupid rule... break connections to the worker 4
route-if = ishigher:${uwsgi[wid]};3 break:403 Forbidden

The 'alarm' routing action
^^^^^^^^^^^^^^^^^^^^^^^^^^

You can now trigger alarms from the routing subsystem:

.. code-block:: ini

[uwsgi]

alarm = pippo cmd:cat

route = ^/help alarm:pippo ${uwsgi[wid]} ${uwsgi[pid]}
http-socket = :9090

when /help is requested the 'pippo' alarm is triggered passing the wid and the pid as the message

Welcome to the ruby shell
^^^^^^^^^^^^^^^^^^^^^^^^^

As well as the --pyshell we now have the ruby shell:

.. code-block:: sh

uwsgi --rbshell -s :3031

or

.. code-block:: sh

uwsgi --rbshell="require 'pry';binding.pry" -s :3031

for using the pry shell: http://pryrepl.org/

... and welcome to the Lua shell
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

As python and ruby, even Lua got its shell. Just add --lua-shell

Goodbye to the old (and useless) probe subsystem
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The probe subsystem was added during 0.9 development cycle but it was badly designed and basically broken.

It has been definitely removed (the deprecation phase has been skipped as 1.9 is not an LTS release and 1.4 still support it)


Improvements in the Legion subsystem (Author: Łukasz Mierzwa)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Two new hooks have been added: --legion-node-joined and --legion-node-left

More fine-tuning
^^^^^^^^^^^^^^^^

--socket-sndbuf and --socket-rcvbuf have been added to allow tuning of the send a receive buffer of the uWSGI sockets (use with caution)

V8 improvements and TeaJS integration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The :doc:`V8` plugin continue to improve. The main target is still :doc:`InternalRouting` but JSGI support is almost complete
and we are working for TeaJS (old v8cgi) integration: http://code.google.com/p/teajs/

more to come soon...


Availability
************

uWSGI 1.9.6 will be available since 20130409 at this url:

https://projects.unbit.it/downloads/uwsgi-1.9.6.tar.gz

Changelog 20130404

Bugfixes
********

* fixed a memory leak with cachestore routing instruction (Riccardo Magliocchetti)
* fixed a memory leak in carbon plugin (Riccardo Magliocchetti)
* fixed a memory leak in the cgi plugin (Riccardo Magliocchetti)
* fixed old-style python dynamic apps
* force the emperor to honour --max-fd for vassals
* improved PSGI seek with post-buffering
* fixed kvlist escaping


New features
************

The GridFS plugin
^^^^^^^^^^^^^^^^^

A plugin exporting GridFS features is available, check official docs: :doc:`GridFS`

V8 improvements
^^^^^^^^^^^^^^^

The V8 plugin continues to improve. Preliminary JSGI 3.0 support is available as well as multithreading.

The 'require' commonjs standard has been implemented.

Writing commonjs specs will be a very long work, so maybe a partnership with projects like teajs (the old v8cgi) would be a better
path to follow.

In the mean time, we are working on docs: :doc:`V8`

The 'cgi' routing instruction
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You can now call CGI script directly from the :doc:`InternalRouting`

.. code-block:: ini

[uwsgi]
plugin = cgi
route = ^/cgi-bin/(.+) cgi:/usr/lib/cgi-bin/$1


Availability
************

uWSGI 1.9.5 will be available since 20130404 at this url

https://projects.unbit.it/downloads/uwsgi-1.9.5.tar.gz

Changelog 20130330

Bugfixes
********

fixed cache statistics exported by the stats subsystem (Łukasz Mierzwa)

fixed CoroEV bug in after_request (Tom Molesworth and John Berthels)

update cache items after a restore from persistent storage (Łukasz Mierzwa)

fixed signal handling in non-worker processes

fixed thundering herd in multiple mules setup

ported the cplusplus skeletal plugin to the new api

fixed uWSGI reloading when build as a shared library

New features
************

SmartOS official support
^^^^^^^^^^^^^^^^^^^^^^^^

From now on, SmartOS is included in the officially supported operating systems

V8 initial support
^^^^^^^^^^^^^^^^^^

The Lua previous suggestion for writing uWSGI routing rules and configurations, woke up lot of javascript users stating that javascript
itself could be a valid alternative. A V8 plugin is now available, supporting RPC, signal handlers and configurations. You need libv8 headers to build it:

.. code-block:: sh

python uwsgiconfig.py --plugin plugins/v8

.. code-block:: js

var config = {};
config['socket'] = [':3031', ':3032', ':3033'];
config['master'] = true;
config['processes'] = 3+1;
config['module'] = 'werkzeug.testapp:test_app';

config;

.. code-block:: sh

uwsgi --plugin v8 --config foo.js

The previous example will allows you to write dynamic configs in javascript, while you can export javascript functions via the RPC subsystem:

.. code-block:: js

function part1(request_uri, remote_addr) {
return '<h1>i am part1 for ' + request_uri + ' ' + remote_addr + "</h1>" ;
}

function part2(request_uri, remote_addr) {
return '<h2>i am part2 for ' + request_uri + ' ' + remote_addr + "</h2>" ;
}

function part3(request_uri, remote_addr) {
return '<h3>i am part3 for ' + request_uri + ' ' + remote_addr + "</h3>" ;
}

uwsgi_register_rpc('part1', part1);
uwsgi_register_rpc('part2', part2);
uwsgi_register_rpc('part3', part3);

.. code-block:: ini

[uwsgi]
plugin = v8
v8-load = func.js
cache2 = name=foobar,items=10

http-socket = :9090

route-run = addheader:Content-Type: text/html
route-run = cache:key=pippo,name=foobar
route-run = cachestore:key=pippo,name=foobar
route-run = rpcnext:part1 ${REQUEST_URI} ${REMOTE_ADDR}
route-run = rpcnext:part2 ${REQUEST_URI} ${REMOTE_ADDR}
route-run = rpcnext:part3 ${REQUEST_URI} ${REMOTE_ADDR}
route-run = break:

The previous example generates an HTTP response from 3 javascript functions and store it in the uWSGI cache.

Curious about rpcnext ?

The rpcnext routing action
^^^^^^^^^^^^^^^^^^^^^^^^^^

We can already call rpc functions from the routing subsystem to generate response. With the rpcnext action (aliased as rpcblob too)
you can call multiple rpc functions and assemble the return values in a single response.

Legion improvements
^^^^^^^^^^^^^^^^^^^

We are hardly working in stabilizing :doc:`Legion` The objective is have a rock-solid clustering implementation for uWSGI 2.0
that you can use even from your applications.

The code in 1.9.4 has been refactored a bit by Łukasz Mierzwa to allow easier integration with external plugins.

A new "join" hook has been added, it is called as soon as a node becomes active part of a legion (read, it is part of a quorum).

Availability
************

uWSGI 1.9.4 will be available since 20130330 at this url

https://projects.unbit.it/downloads/uwsgi-1.9.4.tar.gz

Changelog 20130328


Bugfixes
********

fixed imports in the JVM build system when virtualenvs are used (Ryan Kaskel)

fixed mod_proxy_uwsgi with apache 2.4

fixed php headers generation when Status is created from the php app itself


New features
************

Pluggable configuration system (with Lua support)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

From this version you will be able to implement configurators (like the already available xml, ini, yaml, json, ldap, sqlite...)
as plugins.

The first available configurator is the Lua one (offered by the lua plugin).

This is an example configuration written in lua:

.. code-block:: lua

config = {}

config['immediate-uid'] = 'roberto'
config['immediate-gid'] = 'roberto'
config['http-socket'] = ':9090'
config['env'] = { 'FOO=bar', 'TEST=topogigio' }
config['module'] = 'werkzeug.testapp:test_app'

return config

you can load it with:

.. code-block:: sh

uwsgi --plugin lua --config config.lua

The --config option is the way to load pluggable configurators. You can even override the already available embedded configurators
with your own version.

The Emperor has already been extended to support pluggable configurators:

.. code-block:: ini

[uwsgi]
emperor = /etc/uwsgi/vassals
emperor-extra-extension = .lua
emperor-extra-extension = .foo

adding emperor-extra-extension will allows the emperor to search for the specified extension passing the config file to the vassal with the --config option.

Immediate setuid and setgid
^^^^^^^^^^^^^^^^^^^^^^^^^^^

In a recent uWSGI maling-list thread, the need to not rely on file system permissions for the tyrant mode emerged.

Albeit it is the most secure approach, two new options --immediate-uid and --immediate-gid have been added.

Setting them on top of your vassal file will force the instance to setuid()/setgid() as soon as possible and without the (theoretical) possibility to override them.

The word "theoretical" here is the key, you always need to remember that a security bug in uWSGI could allow a malicious user to change privileges, so if you really
care security (or do not trust uWSGI developers ;) always drop privileges before the vassal/instance is spawned (like in standard tyrant mode)

Honouring symlinks in tyrant mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The option --emperor-tyrant-nofollow has been added forcing the emperor to now follow symlinks when searching for uid/gid in tyrant mode.

This option allows the sysadmin to simply symlink configurations and just change the uid/gid of the symlink it self (remember to
pass the -h option to chown !!!)

The "rpcret" routing action (or usa Lua to write advanced rules)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The :doc:`InternalRouting` continue to be improved.

You can already call rpc function for the routing system (to generate response bypassing WSGI/PSGI/Rack/... engines):

.. code-block:: ini

[uwsgi]
lua-load = myrpcfunctions.lua
route = ^/foo/(.+)/call rpc:hello_world ${REMOTE_ADDR} $1

the hello_world rpc function is defined (and registered) in the myrpcfunctions.lua taking two arguments.

The function is called when the routing regexp matches, and its output sent to the client.

The "rpcret" works in similar way, but instead generating a response, you generate a routing return code:

.. code-block:: lua

function choose(request_uri, remote_addr)
print( 'REQUEST_URI is ' ..request_uri.. ' (from Lua)')
if request_uri == '/topogigio' then
return "goto topogigio"
end
return "break 500 Internal server Error !!!"
end

print('Hello Hello')
uwsgi.register_rpc('choose', choose)

and the uWSGI config:

.. code-block:: ini

[uwsgi]
route-run = rpcret:choose ${REQUEST_URI} ${REMOTE_ADDR}
route-run = break

route-label = topogigio
route-run = log:i am topogigio !!!

The 'choose' rpc function will be invoked at every request passing REQUEST_URI and REMOTE_ADDR as its argument.

The return string of the function will be used to know what to do next (from the internal ruting point of view).

Currently supported return strings are:

``next`` move to the next rule

``continue`` pass the request to the request handler

``goon`` move to the next rule with a different action

``break`` close the connection with an optional status code

``goto <label>`` goto to the specified label


Obviously rpc functions for rpcret can be written in any language/platform supported by uWSGI, but we strongly suggest to go with Lua for performance reasons
(the inpact compared to pure C code is pretty irrelevant). If you are lucky and can use LuaJit you will experiment even better performance as for this kind of job
a JIT compiler is the best approach.


Availability
************

uWSGI 1.9.3 has been released on 20130328 and can be downloaded from:

https://projects.unbit.it/downloads/uwsgi-1.9.3.tar.gz

Changelog 20130326

Bugfixes
********

Fixed python3 response headers managament (wrong refcnt)

Fixed readline() on request body when postbuffering is in place

Fixed ruby fiber plugin

New features
************

route-run and the cachestore routing action
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You can now store responses automatically in the uWSGI cache:

.. code-block:: ini

[uwsgi]
http-socket = :9090
; ensure the sweeper thread will run
master = true
cache2 = name=pippo2,items=10
module = werkzeug.testapp:test_app
route-run = cache:key=${REQUEST_URI},name=pippo2
route-run = cachestore:key=${REQUEST_URI},expires=30,name=pippo2

this example check every request for its availability in the cache 'pippo2'. If not available the request plugin (werkzeug test app)
will run normally and its output will be stored in the cache (only if it returns a HTTP 200 status)

``--route-run`` is a new option allowing you to directly call routing action without checking for a specific condition (yes, it is an optimization)

routing access to cookie and query string
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Check updated docs :doc:`InternalRouting`

empty internal routing condition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Check updated docs :doc:`InternalRouting`

The Geoip plugin
^^^^^^^^^^^^^^^^

Check official docs :doc:`GeoIP`

The SSI plugin (beta)
^^^^^^^^^^^^^^^^^^^^^

Check official docs :doc:`SSI`

Availability
************

uWSGI 1.9.2 has been released on 20130326 and can be downloaded from:

https://projects.unbit.it/downloads/uwsgi-1.9.2.tar.gz