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.
Answer from Dominick Pastore on Stack Overflowflask - What exactly is Werkzeug? - Stack Overflow
Why do Python frameworks like Flask need a WSGI (Werkzeug) but not Node.js?
Werkzeug vs bottle?
What is the best way to find package dependencies for Werkzeug 3.0.x?
Videos
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.
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
Flask uses a 3rd party WSGI, Django has its own WSGI, and FastAPI uses a ASGI. But i've never seen those terms mentioned when reading about Nest.js or Node or Express. Why?
I am just starting in web programming, i know a bit of python. I don't want to code in big projects like django which takes care of all the basic programming details, i just want to build basic web applications to learn programming and web application development. I heard about these two projects and although bottle seems to be a more basic choice, it lacks documentation. Somebody also suggested to try wsgi but it seems to be difficult for a new comer like me. Kindly suggest.
» pip install Werkzeug
Due to a vulnerability, the Werkzeug version needs to be updated to 3.0.3.
I have two microservices, where the build output of one is dependent on the other.
Here are the packages listed in the requirements.txt file of **Service 1:
Flask==2.3.2
Flask-Cors==3.0.10
boto3==1.9.201
**Werkzeug==2.3.8**
markupsafe==2.1.3
tenacity==8.2.1
pep8==1.7.1
mock==4.0.3
moto==2.2.19
pylint==2.12.2
pytest==6.2.5
pytest-cov==3.0.0
pytest-flask==1.3.0
requests-mock==1.8.0
**Service 2:**
Moto
The use case involves recording JSON responses, but it encounters a KeyError when specifying Werkzeug==3.0.x in Service 1. The Werkzeug vulnerability is there in Service 2 as well, introduced through Motothe . There are no depedency issues getting logged in build log.
I have used **pipdeptree** and found that directly upgrading Werkzeug does not work. It seemed there is some dependency on boto3, so I updated both packages as follows:
boto3==1.26.100
Werkzeug==3.0.3
but the build still failed with **KeyError**.
However, this trial-and-error approach is not effective. Is there another solution to this issue? I have also tried using **pip-compile**, but the output is not easy to interpret.
You can install an old package with pip:
pip install Werkzeug==0.9.6
Building on f43d65's comment, I have refined it to these steps which include making sure it is coming from a reliable source:
- goto the official website: http://werkzeug.pocoo.org/
- click link to official github account: https://github.com/mitsuhiko/werkzeug
- click on releases tab: https://github.com/mitsuhiko/werkzeug/releases
Note: the instructions make sure that the download is coming from the official source.