django 源码解析 - 2 http协议处理流程

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
简介: Django是一款经典的Python Web开发框架,是最受欢迎的Python开源项目之一。不同于Flask框架,Django是高度集成的,可以帮助开发者快速搭建一个Web项目。 从上周开始,我们一起进入Djaong项目的源码解析,加深对django的理解,熟练掌握python web开发。在上篇文章中我们首先采用概读法,了解django项目的创建和启动过程。这篇文章我们同样使用概读法,了解diango中http协议的处理流程。这个流程也是客户端的请求如何在django中传递和处理,再返回客户端的过程。

Django是一款经典的Python Web开发框架,是最受欢迎的Python开源项目之一。不同于Flask框架,Django是高度集成的,可以帮助开发者快速搭建一个Web项目。 从上周开始,我们一起进入Djaong项目的源码解析,加深对django的理解,熟练掌握python web开发。在上篇文章中我们首先采用概读法,了解django项目的创建和启动过程。这篇文章我们同样使用概读法,了解diango中http协议的处理流程。这个流程也是客户端的请求如何在django中传递和处理,再返回客户端的过程。本文大概分下面几个部分:


  • tcp && http && wsgi 协议分层
  • 中间件(middleware)链表
  • URL路由搜索
  • 请求(request)和response响应


tcp && http && wsgi 协议分层



接上一篇,我们知道django在runserver命令中启动http服务入口:


# runserver.py
from django.core.servers.basehttp import (
    WSGIServer, get_internal_wsgi_application, run,
)
...
handler = get_internal_wsgi_application()
run(self.addr, int(self.port), handler,
    ipv6=self.use_ipv6, threading=threading, server_cls=WSGIServer)
复制代码


http-server和wsgi-server的实现都在basehttp模块。下面是改模块的结构图:


image.png


从结构图总我们不难发现tcp,http和wsgi的结构层级主要关系大概如下图:


+------------+      +--------------------+
| WSGIServer <------+ WSGIRequestHandler |
+-----+------+      +------+-------------+
      |                    |
      |                    |
+-----v------+      +------v-------------+
| HttpServer <------+ HttpRequestHandler |
+-----+------+      +------+-------------+
      |                    |
      |                    |
+-----v------+      +------v-------------+
|  TCPServer <------+  TCPRequestHandler |
+------------+      +--------------------+
复制代码


  • 每一层服务的实现,都有对应的RequestHandler处理对应协议的请求
  • 客户端的请求从底层的tcp,封装成上层的http请求,再到wsgi请求
  • 上层类都继承自下层类


比较特别的是多出来的ServerHandler和WSGIRequestHandler的关系:


class WSGIRequestHandler(BaseHTTPRequestHandler):
    def handle(self):
        """Handle a single HTTP request"""
        ...
        handler = ServerHandler(
            self.rfile, self.wfile, self.get_stderr(), self.get_environ(),
            multithread=False,
        )
        handler.request_handler = self      # backpointer for logging
        handler.run(self.server.get_app())
复制代码


这里把http请求,委托给支持wsgi的application,也就是django的application。


关于http和wsgi的详细内容,可以参考之前的文章 wsgiref 源码阅读,这里不再详细介绍。


了解三层协议后,我们在看看application的动态载入:


def get_internal_wsgi_application():
    """
    Load and return the WSGI application as configured by the user in
    ``settings.WSGI_APPLICATION``. With the default ``startproject`` layout,
    this will be the ``application`` object in ``projectname/wsgi.py``.
    This function, and the ``WSGI_APPLICATION`` setting itself, are only useful
    for Django's internal server (runserver); external WSGI servers should just
    be configured to point to the correct application object directly.
    If settings.WSGI_APPLICATION is not set (is ``None``), return
    whatever ``django.core.wsgi.get_wsgi_application`` returns.
    """
    ...
    return get_wsgi_application()
复制代码


application实际上是一个WSGIHandler对象实例:


def get_wsgi_application():
    """
    The public interface to Django's WSGI support. Return a WSGI callable.
    Avoids making django.core.handlers.WSGIHandler a public API, in case the
    internal WSGI implementation changes or moves in the future.
    """
    django.setup(set_prefix=False)
    return WSGIHandler()
复制代码


  • 需要注意的是WSGIHandler和WSGIRequestHandler不是同一个类


这个WSGIHandle对象执行了wsgi的实现,接收wsgi-environ,在start_response中处理http状态码和http头,返回http响应。


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 = [
            *response.items(),
            *(('Set-Cookie', c.output(header='')) for c in response.cookies.values()),
        ]
        start_response(status, response_headers)
        ...
        return response
复制代码


另外一个非常重要的点是WSGIHandle对象在初始化时候进行了load_middleware,加载了django的中间件。


中间件(middleware)链条



在开始介绍中间件(middleware)之前,我们先了解一点点基础知识。装饰器模式是python中非常重要的设计模式,也是中间件的基础。下面是一个装饰器的简单示例:


from decorators import debug, do_twice
@debug
@do_twice
def greet(name):
    print(f"Hello {name}")
复制代码


程序的运行结果:


>>> greet("Eva")
Calling greet('Eva')
Hello Eva
Hello Eva
'greet' returned None
复制代码


我们可以看到整个过程是从外至内的,首先是debug装饰器生效,告知开始运行greet函数;然后是do_twice装饰器生效,调用了两次greet函数;最里层的greet目标函数最后执行并返回。取消掉@字符这个语法糖,上面函数的调用过程大概是这样的:


debug(do_twice(greet))(name)
复制代码


  • debug和do_twice的参数和返回值都是函数
  • name是最后一个函数的参数


利用装饰器,我们可以在不修改目标函数的情况下,给函数增加各种额外功能。在django中这是中间件(middleware)的工作。下面是一个最简单的函数式中间件:


def simple_middleware(get_response):
    # One-time configuration and initialization.
    def middleware(request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.
        response = get_response(request)
        # Code to be executed for each request/response after
        # the view is called.
        return response
    return middleware
复制代码


  • simple_middleware是标准的装饰器实现
  • simple_middleware包装WSGIHandler的get_response方法
  • get_response函数处理request然后返回response
  • 2个注释部分预留了可以扩展的空间: 在目标函数执行之前对request进行处理和在目标函数执行之后对response进行处理


实际上所有的middlew都继承自MiddlewareMixin,在其中使用模版模式,定义了process_requestprocess_response

两个待子类扩展的方法,进一步明确了中间件的处理位置:


class MiddlewareMixin:
    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
复制代码


MiddlewareMixin是一个以类方式实现的装饰器


默认的CommonMiddleware中示例了扩展出一个通用的中间件(middleware): 继承自MiddlewareMixin,扩展process_request和process_response方法:


class CommonMiddleware(MiddlewareMixin):
    def process_request(self, request):
        pass
    def process_response(self, request, response):
        pass
复制代码


下面是process_request的全部代码:


def process_request(self, request):
    """
    Check for denied User-Agents and rewrite the URL based on
    settings.APPEND_SLASH and settings.PREPEND_WWW
    """
    # Check for denied User-Agents
    user_agent = request.META.get('HTTP_USER_AGENT')
    if user_agent is not None:
        for user_agent_regex in settings.DISALLOWED_USER_AGENTS:
            if user_agent_regex.search(user_agent):
                raise PermissionDenied('Forbidden user agent')
    # Check for a redirect based on settings.PREPEND_WWW
    host = request.get_host()
    must_prepend = settings.PREPEND_WWW and host and not host.startswith('www.')
    redirect_url = ('%s://www.%s' % (request.scheme, host)) if must_prepend else ''
    # Check if a slash should be appended
    if self.should_redirect_with_slash(request):
        path = self.get_full_path_with_slash(request)
    else:
        path = request.get_full_path()
    # Return a redirect if necessary
    if redirect_url or path != request.get_full_path():
        redirect_url += path
        return self.response_redirect_class(redirect_url)
复制代码


  • 检查http头中的HTTP_USER_AGENT是否被禁止
  • 检查请求的域名是否需要跳转


下面是process_response的全部代码:


def process_response(self, request, response):
    """
    When the status code of the response is 404, it may redirect to a path
    with an appended slash if should_redirect_with_slash() returns True.
    """
    # If the given URL is "Not Found", then check if we should redirect to
    # a path with a slash appended.
    if response.status_code == 404 and self.should_redirect_with_slash(request):
        return self.response_redirect_class(self.get_full_path_with_slash(request))
    # Add the Content-Length header to non-streaming responses if not
    # already set.
    if not response.streaming and not response.has_header('Content-Length'):
        response.headers['Content-Length'] = str(len(response.content))
    return response
复制代码


  • 确保给http响应增加Content-Length的http头


了解单个中间件(middleware)实现后,我们继续看所有中间件协作原理。默认情况下会配置下面这些预制的中间件:


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',
]
复制代码


前面介绍过这些中间件列表是由load_middleware函数处理:


def load_middleware(self, is_async=False):
    ...
    handler = self._get_response
    ...
    for middleware_path in reversed(settings.MIDDLEWARE):
        middleware = import_string(middleware_path)
        ...
        mw_instance = middleware(handler)
        ...
        handler = mw_instance
    ...
    self._middleware_chain = handler
复制代码


  • 通过get_response获取到view的函数
  • 逐一加载中间件类并实例化中间件对象
  • 将所有的中间件对象形成一个链表


中间件可以形成一个链表是因为MiddlewareMixin的结构,每个middleware包括了一个指向后续中间件的引用:


class MiddlewareMixin:
    ...
    def __init__(self, get_response):
        ...
        # 后续处理的指针
        self.get_response = get_response
        ...
        super().__init__()
复制代码


每个wsgi-application的请求响应,都需要调用_middleware_chain处理:


def get_response(self, request):
    """Return an HttpResponse object for the given HttpRequest."""
    # Setup default url resolver for this thread
    set_urlconf(settings.ROOT_URLCONF)
    response = self._middleware_chain(request)
    ...
    return response
复制代码


在werkzeug中,我们介绍过「洋葱模型」:


image.png


可以看到django的middleware也是类似的逻辑,中间件层层包裹形成一个链,可以在穿透和返回过程中对请求和响应各进行一次额外处理。


url-router路由搜索



http的URL和view函数对应,是通过urlpatterns配置。比如下面将api-app的根路径api/和view层的index函数映射起来:


urlpatterns = [
    path('', views.index, name='index'),
]
def index(request):
    return HttpResponse("Hello, Python 2. You're at the index.")
复制代码


django提供了一个些实现,可以根据请求的URL查找到业务View的函数。前面的load_middleware中就是通过_get_response开始查找业务View:


def _get_response(self, request):
    """
    Resolve and call the view, then apply view, exception, and
    template_response middleware. This method is everything that happens
    inside the request/response middleware.
    """
    callback, callback_args, callback_kwargs = self.resolve_request(request)
    ...
    response = callback(request, *callback_args, **callback_kwargs)
    ...
    return response
复制代码


resolver对象根据request.path_info也就是URL查找View函数:


def resolve_request(self, request):
    """
    Retrieve/set the urlconf for the request. Return the view resolved,
    with its args and kwargs.
    """
    # Work out the resolver.
    ...
    resolver = get_resolver()
    # Resolve the view, and assign the match object back to the request.
    resolver_match = resolver.resolve(request.path_info)
    request.resolver_match = resolver_match
    return resolver_match
复制代码


resolver对象通过下面的方式创建:


def get_resolver(urlconf=None):
    if urlconf is None:
        urlconf = settings.ROOT_URLCONF
    return _get_cached_resolver(urlconf)
@functools.lru_cache(maxsize=None)
def _get_cached_resolver(urlconf=None):
    return URLResolver(RegexPattern(r'^/'), urlconf)
复制代码


  • 这里使用了lru_cache来缓存URLResolver对象提高效率


resolve主要使用url的匹配规则查找配置的url_patterns:


def resolve(self, path):
    path = str(path)  # path may be a reverse_lazy object
    tried = []
    match = self.pattern.match(path)
    if match:
        new_path, args, kwargs = match
        for pattern in self.url_patterns:
            try:
                sub_match = pattern.resolve(new_path)
            except Resolver404 as e:
                ...
            return ResolverMatch(
                            sub_match.func,
                            sub_match_args,
                            sub_match_dict,
                            sub_match.url_name,
                            [self.app_name] + sub_match.app_names,
                            [self.namespace] + sub_match.namespaces,
                            self._join_route(current_route, sub_match.route),
                            tried,
                        )
复制代码


url_patterns可以进行二级递归加载:


@cached_property
def urlconf_module(self):
    if isinstance(self.urlconf_name, str):
        return import_module(self.urlconf_name)
    else:
        return self.urlconf_name
@cached_property
def url_patterns(self):
    # urlconf_module might be a valid set of patterns, so we default to it
    patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
    try:
        iter(patterns)
    except TypeError as e:
        ...
    return patterns
复制代码


下面代码示例了在project中,导入app的url,形成一个project-app的二级树状结构。这样的结构设计和flask的蓝图非常类似,对于组织大型web项目非常有用。


from django.contrib import admin
from django.urls import path, include
urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('api.urls')),
]
复制代码


我们可以发现django的router实现实际上是一种懒加载模式,有请求对象才开始初始化。ResolverMatch的算法实现,我们以后再行详细介绍。


请求(request)和response响应



我们再观测django的view函数:


def index(request):
    return HttpResponse("Hello, Python 2. You're at the index.")
复制代码


  • 请求是一个request对象
  • 返回是一个HttpResponse对象


在WSGIHandler中有定义request的类是WSGIRequest:


class WSGIHandler(base.BaseHandler):
    request_class = WSGIRequest
复制代码


request类的继承关系如下:


+-------------+   +-------------+   +--------+
| WSGIRequest +---> HttpRequest +---> object |
+-------------+   +-------------+   +--------+
复制代码


对于request我们跟踪一下http协议的header,query和body如何传递到request对象, 都是通过env对象传递。比如query对象是这样封装到wsgi-env上:


class WSGIRequestHandler(BaseHTTPRequestHandler):
    def get_environ(self):
        if '?' in self.path:
            path,query = self.path.split('?',1)
        else:
            path,query = self.path,''
        env['PATH_INFO'] = urllib.parse.unquote(path, 'iso-8859-1')
        env['QUERY_STRING'] = query
复制代码


wsgi的env会传递给wsgi-application:


class BaseHandler:
    def run(self, application):
        self.setup_environ()
        self.result = application(self.environ, self.start_response)
        self.finish_response()
复制代码


在WSGIRequest中从wsgi-env中读取query放到GET属性上:


@cached_property
def GET(self):
    # The WSGI spec says 'QUERY_STRING' may be absent.
    raw_query_string = get_bytes_from_wsgi(self.environ, 'QUERY_STRING', '')
    return QueryDict(raw_query_string, encoding=self._encoding)
复制代码


比如body是在stdin上,也是封装在env的 wsgi.input key上:


class BaseHandler:
    def setup_environ(self):
        """Set up the environment for one request"""
        ...
        env['wsgi.input']        = self.get_stdin()
        ...
复制代码


在WSGIRequest中使用LimitedStream封装一下:


class WSGIRequest(HttpRequest):
    def __init__(self, environ):
        self._stream = LimitedStream(self.environ['wsgi.input'], content_length)
复制代码


这样body就从这个流中读取:


@property
    def body(self):
        if not hasattr(self, '_body'):
            ...
            try:
                self._body = self._stream.read()
            except OSError as e:
                raise UnreadablePostError(*e.args) from e
            self._stream = BytesIO(self._body)
        return self._bod
复制代码


http的响应处理则不太一样,view返回的是普通的HttpResponse对象,在wsgi框架中将其转换写入到stdout中:


class SimpleHandler(BaseHandler):
    def _write(self,data):
        result = self.stdout.write(data)
        ...
        while True:
            data = data[result:]
            if not data:
                break
            result = self.stdout.write(data)
...
def finish_response(self):
    """Send any iterable data, then close self and the iterable
    Subclasses intended for use in asynchronous servers will
    want to redefine this method, such that it sets up callbacks
    in the event loop to iterate over the data, and to call
    'self.close()' once the response is finished.
    """
    try:
        if not self.result_is_file() or not self.sendfile():
            for data in self.result:
                self.write(data)
            self.finish_content()
    except:
        ...
    else:
        # We only call close() when no exception is raised, because it
        # will set status, result, headers, and environ fields to None.
        # See bpo-29183 for more details.
        self.close()
复制代码


具体到http模块下的HttpRequest和HttpResponse的实现,就是比较存粹的python对象,我认为这也是sansio的实现。


sansio.Request是non-IO理念的HTTP request实现,希望IO和逻辑像三明治(sandwich)一样,分层in-IO/业务逻辑/out-IO三层。这种方式实现的Request对象比较抽象,不涉及io和aio具体实现,比较通用,而且可以 快速测试 。如果wsgi的实现,推荐使用上层的 werkzeug.wrappers.Request


image.png


小结



通过对django的wsgi模块进行分析,我们梳理了tcp,http和wsgi的三层关系,了解了wsgi-application和wsgi-handler之间的委托方式。然后分析了中间件(middleware)的构造,加载方式和多个中间件如何构成中间件链表并对请求进行额外的处理。分析了如何通过http的URL路由到对应的view函数,进行业务响应。最后对django的request和response对象如何和http协议进行结合进行了简单分析。


完成上面四个步骤的分析后,我们可以知道远程的http请求如何传递到业务view函数并进行响应返回的整个流程。


参考链接





目录
相关文章
|
27天前
|
安全 网络协议 网络安全
IP代理的三大协议:HTTP、HTTPS与SOCKS5的区别
**HTTP代理**适用于基本网页浏览,简单但不安全;**HTTPS代理**提供加密,适合保护隐私;**SOCKS5代理**灵活强大,支持TCP/UDP及认证,适用于绕过限制。选择代理协议应考虑安全、效率及匿名需求。
|
4天前
|
存储 JavaScript 前端开发
Django + Vue 实现图片上传功能的全流程配置与详细操作指南
 在现代Web应用中,图片上传是一个常见且重要的功能。Django作为强大的Python Web框架,结合Vue.js这样的现代前端框架,能够高效地实现这一功能。本文将详细介绍如何在Django项目中配置图片上传的后端处理,并在Vue前端实现图片的选择、预览和上传功能。
|
6天前
|
存储 缓存
解析HTTP通用首部字段
【7月更文挑战第18天】HTTP通用首部字段是指,请求报文和响应报文双方都会使用的首部。
|
13天前
|
SQL 安全 数据安全/隐私保护
DVWA Open HTTP Redirect 通关解析
DVWA Open HTTP Redirect 通关解析
|
12天前
|
存储 安全 搜索推荐
HTTPS协议深度解析
【7月更文挑战第12天】HTTPS协议通过加密通信和身份验证机制,为数据传输提供了强有力的安全保障。在现代互联网环境中,HTTPS已成为保障网站和用户数据安全的重要手段。了解HTTPS的工作原理和安全性特性,有助于更好地应用和维护HTTPS,提升网络安全水平。
|
21天前
|
域名解析 Web App开发 缓存
在浏览器上输入一个网址后,发生了什么?/HTTP的工作流程/DNS域名解析过程
在浏览器上输入一个网址后,发生了什么?/HTTP的工作流程/DNS域名解析过程
|
27天前
|
安全 网络协议 算法
Android网络基础面试题之HTTPS的工作流程和原理
HTTPS简述 HTTPS基于TCP 443端口,通过CA证书确保服务器身份,使用DH算法协商对称密钥进行加密通信。流程包括TCP握手、证书验证(公钥解密,哈希对比)和数据加密传输(随机数加密,预主密钥,对称加密)。特点是安全但慢,易受特定攻击,且依赖可信的CA。每次请求可能复用Session ID以减少握手。
28 2
|
1月前
|
域名解析 存储 缓存
HTTP请求流程概览:浏览器构建请求行含方法、URL和版本;检查缓存;解析IP与端口
【6月更文挑战第23天】 HTTP请求流程概览:浏览器构建请求行含方法、URL和版本;检查缓存;解析IP与端口;TCP连接(HTTP/1.1可能需排队);三次握手;发送请求头与体;服务器处理并返回响应;TCP连接可能关闭或保持;浏览器接收并显示响应,更新缓存。HTTP版本间有差异。
37 5
|
28天前
|
前端开发 数据库 开发者
构建高效后端:Django框架在Web开发中的深度解析
**Django框架深度解析摘要** Django,Python的高级Web框架,以其快速开发和简洁设计备受青睐。核心特性包括Model-Template-View架构、ORM、模板引擎和URL路由。通过创建博客应用示例,展示从初始化项目、定义模型、创建视图和URL配置到使用模板的流程,体现Django如何简化开发,提高效率。其强大功能如用户认证、表单处理等,使Django成为复杂Web应用开发的首选。学习Django,提升Web开发效率。【6月更文挑战第24天】
56 1
|
19天前
|
数据安全/隐私保护
https【详解】与http的区别,对称加密,非对称加密,证书,解析流程图
https【详解】与http的区别,对称加密,非对称加密,证书,解析流程图
13 0

推荐镜像

更多