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.