Heim  >  Artikel  >  Backend-Entwicklung  >  Anforderungsprozess für die Analyse des Django-Quellcodes

Anforderungsprozess für die Analyse des Django-Quellcodes

little bottle
little bottlenach vorne
2019-04-08 17:48:182076Durchsuche

Das Django-Projekt ist ein benutzerdefiniertes Python-Framework, das von einer Online-Nachrichten-Website stammt und 2005 als Open Source veröffentlicht wurde. In diesem Artikel wird eine Quellcodeanalyse des Django-Anfrageprozesses durchgeführt.

1. Wie läuft der Prozess von der Anfrage des Browsers bis zur Rückgabe des Antwortinhalts ab?

1. Der Browser analysiert die eingegebene URL

2. Findet die der URL entsprechende IP-Adresse

Zugriff auf unseren Server über die IP-Adresse

 a . Die Anfrage geht an den WSGI-Server (ich habe hier den möglichen Proxy-Server weggelassen, z. B. Nginx)

Der WSGI-Server verpackt die Anfrage und leitet sie an die Django-Anwendung weiter

c. Die Django-Anwendung basiert auf dem Anforderungspfad, der die entsprechende Verarbeitungsfunktion zur Verarbeitung findet.

d. Nach Abschluss der Verarbeitung gibt die Django-Anwendung die Antwort an den WSGI-Server zurück. Der WSGI-Server verpackt die von der Django-Anwendung zurückgegebene Antwort und gibt die Antwort zurück

4. Der Server gibt den Antwortinhalt zurück und der Browser rendert die Ausgabe

2. Der Verarbeitungseingang des Django Anwendung

Der wsgi-Dienst kommuniziert mit der Django-Anwendung über das wsgi-Protokoll. Der wsgi-Dienst ist die Serverseite, und die Django-Anwendung ist eine Anwendung. Die Serverseite ruft die Djano-Anwendung über die von Django bereitgestellte Funktion application_callable auf . Nachdem die application_callable-Funktion verarbeitet wurde, wird die Antwort an den Server zurückgegeben

django Die application_callable-Funktion befindet sich in der Datei django.core.handlers.wsgi.py Der Server ruft die WSGIHandler-Klasse auf, wenn jede Anfrage verarbeitet wird

#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

3. Django verarbeitet den Anforderungsprozess

Die WSGIHandler-Klasse befindet sich in. Laden Sie beim Initialisieren zuerst die Middleware und kapseln Sie die angeforderte Funktion _get_response mit Middleware (Middleware). entspricht einem Dekorator), wenn die Middleware ausgeführt wird

# wsgi.py文件
# 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

Als nächstes ruft die Anfrage WSGIHandler auf

1 instanziieren eine request_class

2 get_response, get_response ruft schließlich die von der Middleware gekapselte Funktion _get_response

def _get_response(self, request):
    response = None

    if hasattr(request, 'urlconf'):
        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

_get_response-Funktion auf. Zuerst wird die aufzurufende Ansichtsfunktion anhand der URL

discoverer_match =solver.resolve(request.path_info) gefunden )

, und dann wird die Ansichtsfunktion Response = Wrapped_callback(request, *callback_args, **callback_kwargs) aufgerufen. Geben Sie die Antwort zurück (einige Middleware wird auch in _get_response aufgerufen) An diesem Punkt wird die Antwort an den Server zurückgegeben und der gesamte Anforderungsprozess ist abgeschlossen

4. Zusammenfassung

django Für eine Anfrage besteht der Hauptprozess darin, die entsprechende Ansichtsfunktion zu finden Rufen Sie auf die Anfrage die von der Middleware gekapselte Ansichtsfunktion auf und geben Sie die Antwort zurück.

[Empfohlener Kurs:

Django-Video-Tutorial

]

Das obige ist der detaillierte Inhalt vonAnforderungsprozess für die Analyse des Django-Quellcodes. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:cnblogs.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen
Vorheriger Artikel:[Python-Lernen] DateioperationNächster Artikel:[Python-Lernen] Dateioperation