This paper refers to:

  • Wikipedia : Web Server Gateway Interface
  • WSGI: The Server-Application Interface for Python
  • wsgi.tutorial.codepoint.net/intro
  • Flask: Application startup process

To understand WSGi, you first need to distinguish between the concepts of Server and app.

This figure comes from: www.toptal.com/python/pyth…

Uwsgi and Gunicorn are servers. Django, Flask and Sanic are apps. App is a callable object. The server will parse the request data and send it to APP. After the APP runs the business logic, the result will be returned to the server.

In real life, when we deploy, we might add an nginx in front of the server, so the process can be summarized as follows:

App can be nested -> Middleware

App is a callable, which means I can call App2 from app1, and app3 from App2, and so on. Isn’t it middleware?

If you look at the Djangos Middleware source code, you’ll see MiddlewareMixin:

class MiddlewareMixin:
    def __init__(self, get_response=None):
        self.get_response = get_response
        super().__init__()

    def __call__(self, request):
        response = None
        if hasattr(self, 'process_request'):
            response = self.process_request(request)
        response = response or self.get_response(request)
        if hasattr(self, 'process_response'):
            response = self.process_response(request, response)
        return response
Copy the code

Defines a __call__ method, which is a callable object.

What you define in your Django configuration file:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware'.'django.contrib.sessions.middleware.SessionMiddleware'.'django.middleware.common.CommonMiddleware'.'django.middleware.csrf.CsrfViewMiddleware'.'django.contrib.auth.middleware.AuthenticationMiddleware'.'django.contrib.messages.middleware.MessageMiddleware'.'django.middleware.clickjacking.XFrameOptionsMiddleware',]Copy the code

As it runs, it calls middleware one by one until it reaches your business logic code (the final app part).

More on middleware development later.

The interface that the APP exposes to the server

App is a callable object that needs to receive some parameters, as follows:

def app(environ,start_response):
    pass
Copy the code

Take a look at these two parameters:

  • Environ is a dictionary that protects request information.

Such as server received a GET HTTP: / / http://localhost:8000/auth? User = obiwan&Token =123 This request generates an environ dictionary like this:

This contains all the necessary information for this request. Using this dictionary, the app will know that the path of this request is /auth, so it knows which handler function to call. You can also know the value of the cookie from HTTP_COOKIE, which can then be targeted to a specific user.

  • start_response(status, headers,errors)

The callback function that the Server passes to the app, which needs to be called before returning data to the Server, notifying the Server that it is time to retrieve the returned data.

I heard that this parameter has been almost abandoned, do not need to fully understand. WSGI: The Server-Application Interface for Python

If you love computer science and basic logic like me, welcome to follow my wechat official account: