Processus de demande d'analyse du code source Django

little bottle
Libérer: 2019-04-08 17:49:01
avant
2068 Les gens l'ont consulté

Le projet Django est un framework Python personnalisé issu d'un site Web d'informations en ligne et publié en open source en 2005. Cet article effectuera une analyse du code source du processus de requête de Django.

1. Quel est le processus depuis le navigateur émettant une demande pour renvoyer le contenu de la réponse ?

1. Le navigateur analyse l'url saisie

2 Trouve l'adresse IP correspondant à l'url

3. Accédez à notre serveur via l'adresse IP

 a . La requête entre dans le serveur wsgi (j'ai omis ici l'éventuel serveur proxy, tel que nginx)

b. Le serveur wsgi emballe la requête et la transmet à l'application Django

. c. L'application Django est basée sur Le chemin de la requête trouve la fonction de traitement correspondante pour le traitement

d. Une fois le traitement terminé, l'application Django renvoie la réponse au serveur wsgi

e. Le serveur wsgi conditionne la réponse renvoyée par l'application Django et renvoie la réponse

4. Le serveur renvoie le contenu de la réponse et le navigateur restitue la sortie

2. L'entrée de traitement du Django. application

Le service wsgi communique avec l'application Django via le protocole wsgi. Le service wsgi C'est le côté serveur, et l'application Django est l'application Le côté serveur appelle l'application Djano via la fonction application_callable fournie par Django. .Une fois la fonction application_callable traitée, la réponse est renvoyée au serveur

django La fonction application_callable se trouve dans le fichier django.core.handlers.wsgi.py. Le serveur traite chaque requête, il appellera la classe WSGIHandler

#wsgi.py文件
class WSGIHandler(base.BaseHandler):
    request_class = WSGIRequest
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.load_middleware()
    def __call__(self, environ, start_response):
        set_script_prefix(get_script_name(environ))
        signals.request_started.send(sender=self.__class__, environ=environ)
        request = self.request_class(environ)
        response = self.get_response(request)
        response._handler_class = self.__class__
        status = '%d %s' % (response.status_code, response.reason_phrase)
        response_headers = list(response.items())
        for c in response.cookies.values():
            response_headers.append(('Set-Cookie', c.output(header='')))
        start_response(status, response_headers)
        if getattr(response, 'file_to_stream', None) is not None and environ.get('wsgi.file_wrapper'):
            response = environ['wsgi.file_wrapper'](response.file_to_stream)
        return response
Copier après la connexion
3. Processus de traitement des requêtes Django

WSGIHandler Lorsque la classe est initialisée, elle charge d'abord le middleware et encapsule la fonction demandée. _get_response avec middleware (le middleware est équivalent à un décorateur). Une fois exécuté, le middleware exécutera

# wsgi.py文件
Copier après la connexion
# wsgi.py文件
def load_middleware(self):
  ...


    self._view_middleware = []
    self._template_response_middleware = []
    self._exception_middleware = []

    handler = convert_exception_to_response(self._get_response)
    for middleware_path in reversed(settings.MIDDLEWARE):
        middleware = import_string(middleware_path)
        try:
            mw_instance = middleware(handler)
        except MiddlewareNotUsed as exc:
       ...

            

        handler = convert_exception_to_response(mw_instance)

    self._middleware_chain = handler
Copier après la connexion
Ensuite, la requête consiste à appeler WSGIHandler

1.

2. Obtenez la requête via get_response, et get_response finira par appeler la fonction _get_response

< qui est encapsulée par le middleware. Dans la fonction 🎜>

_get_response, la fonction d'affichage à appeler sera d'abord être trouvé selon l'URL
def _get_response(self, request):
    response = None

    if hasattr(request, &#39;urlconf&#39;):
        urlconf = request.urlconf
        set_urlconf(urlconf)
        resolver = get_resolver(urlconf)
    else:
        resolver = get_resolver()

    resolver_match = resolver.resolve(request.path_info)
    callback, callback_args, callback_kwargs = resolver_match
    request.resolver_match = resolver_match

    ...

    if response is None:
        wrapped_callback = self.make_view_atomic(callback)
        try:
            response = wrapped_callback(request, *callback_args, **callback_kwargs)
        except Exception as e:
            response = self.process_exception_by_middleware(e, request)

    ...

    return response
Copier après la connexion
solver_match = solver.resolve(request.path_info)

, puis la fonction d'affichage réponse = enveloppé_callback(request, * callback_args, **callback_kwargs)Renvoyer la réponse (Certains middlewares seront également appelés dans _get_response)À ce stade, la réponse est renvoyée au serveur et l'ensemble du processus de demande est terminé

Quatre, Résumé

Pour une requête, le processus principal de Django est de trouver la fonction view correspondant à la requête, d'appeler la fonction view encapsulée par le middleware, et de renvoyer la réponse.

[Cours recommandé :

Tutoriel vidéo Django

]

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:cnblogs.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal