What exactly is Werkzeug?

Question

From the official documentation:

Werkzeug is a WSGI utility library for Python.

However, when I run my Flask web application, I notice that the response header from the server contains:

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 13
Server: Werkzeug/0.11.9 Python/2.7.10
Date: Tue, 03 May 2016 12:50:08 GMT

On the fourth line the server is mentioning a Werkzeug, but what exactly is Werkzeug, is it a web server like Apache?

Charyl

Answer 1

No, it is not a web server like Apache. It's a CGI library. Since Apache (or your Flask application) is probably using the library to serve some HTTP requests, it probably adds that header into the response.

Conjunctive

Is there any method to check the exact server the web application is using? I thought that the request header would show the server in Server: line. – Charyl

Usually what's on the "Server" header is accurate. But do keep in mind that if someone wants to hide that information, she could easily change that header to whatever she wants (if she's the one running the web server) – Conjunctive

In this case the header information is most probably correct. Since werkzeug does ship with a small development webserver - which is probably what produced the above response. We'll only know for sure if the OP explains his setup in somewhat more detail... – Catmint

Werkzeug is not a CGI library. It’s a WSGI application library. There are huge differences between CGI and WSGI. – Benedic

Is this werkzueg the flask development server? – Store

@Store Werkzeug is a collection of tools for building a web app. (The word "Werkzeug" is literally German for "tool".) Flask is basically just a higher-level wrapper around Werkzeug that combines those tools into a framework. One of the tools provided by Werkzeug is a development server, and yes, the Flask development server is one and the same as the Werkzeug development server. – Sanatorium

Answer 2

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.

Wiretap

Thanks for the great answer. I'm still a bit confused about the concept here: I learnt that WSGI is this intermediate layer between a web server and a web application. So in flask, if workzeug is acting as a simple web server (in development), who is acting as the WSGI middle layer? – Chili

@Chili It's still Werkzeug. I'm not quite sure I would call WSGI a layer in itself—it's more like a specification for how the application layer and the server layer connect. (Take another look at the bullet points in the answer: That is WSGI.) Werkzeug handles the application side of WSGI for you. However, when you use the development server, it also handles the server side, using an additional module. – Wiretap

Answer 3

No it isn't

Werkzeug(WSGI library) is like a communicator between your python code and http nginx/apache server

Here is the Complete use case of Werkzeug WSGI:

WSGI has two sides: the "server" or "gateway" side (often a web server such as Apache or Nginx), and the "application" or "framework" side (the Python script itself). To process a WSGI request, the server side executes the application and provides environment information and a callback function to the application side. The application processes the request, returning the response to the server side using the callback function it was provided.

Between the server and the application, there may be a WSGI middleware, which implements both sides of the API. The server receives a request from a client and forwards it to the middleware. After processing, it sends a request to the application. The application's response is forwarded by the middleware to the server and ultimately to the client. There may be multiple middlewares forming a stack of WSGI-compliant applications.

Hope it helps

Rattlebrain

Answer 4

Because it's not.

In your setup your most probably using the "development server" (the run_simple function) for testing. So it is in this use-case like a (very) poor man's Apache, but only in a sense that it's able to answer HTTP requests correctly.

If you check the docs http://werkzeug.pocoo.org/docs/serving/ , you'll see the following note:

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.

Catmint