Werkzeug is primarily a library, not a web server, although it does provide a simple web server for development purposes. That development server is what's providing that Server: header.

To go into more detail:

First, let's talk about WSGI. There are a bunch of web servers out there, like Apache, Nginx, Lighttpd, etc. There are also a bunch of web frameworks written in Python, e.g. Django, Flask, Tornado, Pyramid, etc. It would be awfully convenient if these were all interoperable. That's where WSGI comes in. The idea is this:

• There are two sides involved in responding to a client's HTTP request: the web server and the web application. The server handles the intricacies of the network connections, receiving the request, and sending the response. The application takes the request data, acts on it, and crafts the response for the server to send back.

• If you want to write a Python web application, make sure it has a callable object (such as a function) that accepts certain parameters for HTTP headers, input form data, environment variables, etc.

• If you want to write a web server that serves Python apps, make it call that callable object from the application every time an HTTP request comes in.

• The WSGI specification (in PEP 3333) specifies exactly what the parameters for that callable must be and what the return value should be, so every server knows how to talk to every application and vice versa.

So, we know that every web application needs to provide this callable and be able to handle the specific parameters it receives. Every application needs to do this... That sounds like a good opportunity to use a library. Werkzeug is this library.

Werkzeug provides a bunch of utilities for developing WSGI-compliant applications. These utilities do things like parsing headers, sending and receiving cookies, providing access to form data, generating redirects, generating error pages when there's an exception, even providing an interactive debugger that runs in the browser. It's really quite comprehensive. Flask then builds upon this foundation (and Jinja, Click, etc.) to provide a complete web framework.

So, if Werkzeug is a library for applications, why is it showing up in the server header?

Werkzeug does have a module for the server role as well. This is purely for convenience purposes.

Installing and configuring a full-fledged web server like Apache or Nginx is a lot of effort, and almost certainly overkill just for testing your application on your own development box. For that reason, Werkzeug provides a development server: a simple web server that you can run with a single command and almost no configuration. When you do flask run (or werkzeug.serving.run_simple()), this development server is what you are getting. And the Server: header for the development server is—you guessed it—Werkzeug/<version> Python/<version>.

This server isn't meant for production use. At the very least, according to the docs, it doesn't scale well. But I wouldn't be surprised if there were other concerns as well, such as security.

Flask and Werkzeug are different things. Flask contains Werkzeug as one of the things in it, but also has much more (which might be unwanted).

Flask is a web microframework. Werkzeug is a WSGI middleware.

WSGI stands for Web Server Gateway Interface, (mostly) defined by PEP 333 at http://www.python.org/dev/peps/pep-0333/ .

It is an effort by the Python community to establish a standard mechanism for web servers to speak to Python applications.

In theory, any wsgi compliant server (or extension to an existing web server) should be able to load and run any wsgi compliant application.

werkzeug is a web application framework which can run under a compliant WSGI server, such as Apache+mod_wsgi. It also contains a built-in development server that you can use for development.

WSGI can be very confusing at first, but it is actually pretty simple. The WSGI spec requires that your python application do the following:

1. define a callable named application
2. said callable should accept 2 parametes: (environ, start_response)
3. environ is a dictionary of environment variables
4. start_response is a callable that needs called to start the response

Once application is called, then it handles the request, builds the output, and:

1. calls start_response('200 OK', Headers)
2. return [content]

A simple WSGI app might look like this:

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                    ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

It is strongly suggested that you use an existing WSGI framework, as there are a lot of details involved in parsing HTTP requests, handling file uploads, encoding characters, etc...

Take a look at Bottle, Flask, werkzeug, AppStruct, etc...