Former-commit-id:a02aeb236c
[formerly9f19e3f712
] [formerly06a8b51d6d
[formerly 64fa9254b946eae7e61bbc3f513b7c3696c4f54f]] Former-commit-id:06a8b51d6d
Former-commit-id:3360eb6c5f
125 lines
4.7 KiB
ReStructuredText
Executable file
125 lines
4.7 KiB
ReStructuredText
Executable file
=========================
|
|
Serving WSGI Applications
|
|
=========================
|
|
|
|
.. module:: werkzeug
|
|
|
|
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 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.
|
|
|
|
.. autofunction:: run_simple
|
|
|
|
.. admonition:: Information
|
|
|
|
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
|
|
:ref:`deployment` pages.
|
|
|
|
Virtual Hosts
|
|
-------------
|
|
|
|
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
|
|
:ref:`routing` system to dispatch between different hosts or parse
|
|
:attr:`request.host` yourself.
|
|
|
|
Troubleshooting
|
|
---------------
|
|
|
|
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::
|
|
|
|
::1 localhost
|
|
|
|
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`)
|
|
|
|
.. _hosts file: http://en.wikipedia.org/wiki/Hosts_file
|
|
|
|
SSL
|
|
---
|
|
|
|
.. versionadded:: 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 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. You can generate a
|
|
certificate and key in advance and provide the SSL context when the server
|
|
is started::
|
|
|
|
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::
|
|
|
|
$ openssl genrsa 1024 > ssl.key
|
|
$ openssl req -new -x509 -nodes -sha1 -days 365 -key ssl.key > ssl.cert
|