There are many ways to serve a WSGI application. While you’re developing it, you usually don’t want to have a full-blown webserver like Apache up and running, but instead a simple standalone one. Because of that Werkzeug comes with a builtin development server.
The easiest way is creating a small start-myproject.py file that runs the application using the builtin server:
#!/usr/bin/env python # -*- coding: utf-8 -*- from werkzeug.serving import run_simple from myproject import make_app app = make_app(...) run_simple('localhost', 8080, app, use_reloader=True)
You can also pass it the extra_files keyword argument with a list of additional files (like configuration files) you want to observe.
Start an application using wsgiref and with an optional reloader. This wraps wsgiref to fix the wrong default reporting of the multithreaded WSGI variable and adds optional multithreading and fork support.
New in version 0.5: static_files was added to simplify serving of static files as well as passthrough_errors.
New in version 0.6: support for SSL was added.
New in version 0.8: Added support for automatically loading a SSL context from certificate file and private key.
Creates an SSL key for development. This should be used instead of the 'adhoc' key which generates a new cert on each server start. It accepts a path for where it should store the key and cert and either a host or CN. If a host is given it will use the CN *.host/CN=host.
For more information see run_simple().
New in version 0.9.
The development server is not intended to be used on production systems. It was designed especially for development purposes and performs poorly under high load. For deployment setups have a look at the Application Deployment pages.
Many web applications utilize multiple subdomains. This can be a bit tricky to simulate locally. Fortunately there is the hosts file that can be used to assign the local computer multiple names.
This allows you to call your local computer yourapplication.local and api.yourapplication.local (or anything else) in addition to localhost.
You can find the hosts file on the following location:
Windows %SystemRoot%\system32\drivers\etc\hosts Linux / OS X /etc/hosts
You can open the file with your favorite text editor and add a new name after localhost:
127.0.0.1 localhost yourapplication.local api.yourapplication.local
Save the changes and after a while you should be able to access the development server on these host names as well. You can use the URL Routing system to dispatch between different hosts or parse request.host yourself.
New in version 0.7.
Starting with Werkzeug 0.7 the development server provides a way to shut down the server after a request. This currently only works with Python 2.6 and later and will only work with the development server. To initiate the shutdown you have to call a function named 'werkzeug.server.shutdown' in the WSGI environment:
def shutdown_server(environ): if not 'werkzeug.server.shutdown' in environ: raise RuntimeError('Not running the development server') environ['werkzeug.server.shutdown']()
On operating systems that support ipv6 and have it configured such as modern Linux systems, OS X 10.4 or higher as well as Windows Vista some browsers can be painfully slow if accessing your local server. The reason for this is that sometimes “localhost” is configured to be available on both ipv4 and ipv6 socktes and some browsers will try to access ipv6 first and then ivp4.
At the current time the integrated webserver does not support ipv6 and ipv4 at the same time and for better portability ipv4 is the default.
If you notice that the web browser takes ages to load the page there are two ways around this issue. If you don’t need ipv6 support you can disable the ipv6 entry in the hosts file by removing this line:
Alternatively you can also disable ipv6 support in your browser. For example if Firefox shows this behavior you can disable it by going to about:config and disabling the network.dns.disableIPv6 key. This however is not recommended as of Werkzeug 0.6.1!
Starting with Werkzeug 0.6.1, the server will now switch between ipv4 and ipv6 based on your operating system’s configuration. This means if that you disabled ipv6 support in your browser but your operating system is preferring ipv6, you will be unable to connect to your server. In that situation, you can either remove the localhost entry for ::1 or explicitly bind the hostname to an ipv4 address (127.0.0.1)
New in version 0.6.
The builtin server supports SSL for testing purposes. If an SSL context is provided it will be used. That means a server can either run in HTTP or HTTPS mode, but not both. This feature requires the Python OpenSSL library.
The easiest way to do SSL based development with Werkzeug is by using it to generate an SSL certificate and private key and storing that somewhere and to then put it there. For the certificate you need to provide the name of your server on generation or a CN.
Generate an SSL key and store it somewhere:
>>> from werkzeug.serving import make_ssl_devcert >>> make_ssl_devcert('/path/to/the/key', host='localhost') ('/path/to/the/key.crt', '/path/to/the/key.key')
Now this tuple can be passed as ssl_context to the run_simple() method:
You will have to acknowledge the certificate in your browser once then.
Instead of using a tuple as ssl_context you can also create the context programmatically. This way you have better control over it:
from OpenSSL import SSL ctx = SSL.Context(SSL.SSLv23_METHOD) ctx.use_privatekey_file('ssl.key') ctx.use_certificate_file('ssl.cert') run_simple('localhost', 4000, application, ssl_context=ctx)
A key and certificate can be created in advance using the openssl tool instead of the make_ssl_devcert(). This requires that you have the openssl command installed on your system:
$ openssl genrsa 1024 > ssl.key $ openssl req -new -x509 -nodes -sha1 -days 365 -key ssl.key > ssl.cert
The easiest way to enable SSL is to start the server in adhoc-mode. In that case Werkzeug will generate an SSL certificate for you:
run_simple('localhost', 4000, application, ssl_context='adhoc')
The downside of this of course is that you will have to acknowledge the certificate each time the server is reloaded. Adhoc certificates are discouraged because modern browsers do a bad job at supporting them for security reasons.