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 … Read more
Okay, I think I get this now. Why can’t nginx directly call my Flask application? Because nginx doesn’t support the WSGI spec. Technically nginx could implement the WSGI spec if they wanted, they just haven’t. That being the case, we need a web server that does implement the spec, which is what the uWSGI server … Read more
From a totally step-back point of view, Blankman, here is my “Intro Page” for Web Server Gateway Interface: PART ONE: WEB SERVERS Web servers serve up responses. They sit around, waiting patiently, and then with no warning at all, suddenly: a client process sends a request. The client process could be a web server, a … Read more
How WSGI, CGI, and the frameworks are all connected? Apache listens on port 80. It gets an HTTP request. It parses the request to find a way to respond. Apache has a LOT of choices for responding. One way to respond is to use CGI to run a script. Another way to respond is to … Read more
When running the development server – which is what you get by running app.run(), you get a single synchronous process, which means at most 1 request is being processed at a time. By sticking Gunicorn in front of it in its default configuration and simply increasing the number of –workers, what you get is essentially … Read more
A blueprint is a template for generating a “section” of a web application. You can think of it as a mold: You can take the blueprint and apply it to your application in several places. Each time you apply it the blueprint will create a new version of its structure in the plaster of your … Read more