The SPDY router (uWSGI 1.9)¶
Starting from uWSGI 1.9 the HTTPS router has been extended to support version 3 of the SPDY protocol.
To run the HTTPS router with SPDY support, use the
uwsgi --https2 addr=0.0.0.0:8443,cert=foobart.crt,key=foobar.key,spdy=1 --module werkzeug.testapp:test_app
This will start an HTTPS router on port 8443 with SPDY support, forwarding requests to the Werkzeug’s test app the instance is running. If you’ll go to https://address:8443/ with a SPDY-enabled browser, you will see additional WSGI variables reported by Werkzeug:
SPDY.version– protocol version (generally
SPDY.stream– stream identifier (an odd number).
Opening privileged ports as a non-root user will require the use of the shared-socket option and a slightly different syntax:
uwsgi --shared-socket :443 --https2 addr==0,cert=foobart.crt,key=foobar.key,spdy=1 --module werkzeug.testapp:test_app --uid user
Both HTTP and HTTPS can be used at the same time (=0 and =1 are references to the privileged ports opened by shared-socket commands):
uwsgi --shared-socket :80 --shared-socket :443 --http =0 --https2 addr==1,cert=foobart.crt,key=foobar.key,spdy=1 --module werkzeug.testapp:test_app --uid user
- You need at least OpenSSL 1.x to use SPDY (all modern Linux distributions should have it).
- During uploads, the window size is constantly updated.
--http-timeoutdirective is used to set the SPDY timeout. This is the maximum amount of inactivity after the SPDY connection is closed.
PINGrequests from the browsers are all acknowledged.
- On connect, the SPDY router sends a settings packet to the client with optimal values.
- If a stream fails in some catastrophic way, the whole connection is closed hard.
RSTmessages are always honoured.
- Add old SPDY v2 support (is it worth it?)
- Allow PUSHing of resources from the uWSGI cache
- Allow tuning internal buffers