Промежуточное ПО ¶

Написание собственного промежуточного программного обеспечения ¶

Фабрика промежуточного программного обеспечения - это вызываемый объект, который принимает get_response вызываемый объект и возвращает промежуточное программное обеспечение. Промежуточное ПО - это вызываемый объект, который принимает запрос и возвращает ответ, как и представление.

Промежуточное ПО можно записать как функцию, которая выглядит следующим образом:

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

Или его можно записать как класс, экземпляры которого вызываются, например:

class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.

    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.

        response = self.get_response(request)

        # Code to be executed for each request/response after
        # the view is called.

        return response

get_response Вызываемый при условии Джанго может быть фактическим вид (если это последний в списке промежуточного слоя) , или он может быть следующим промежуточным слоем в цепи. Текущее промежуточное программное обеспечение не должно знать или заботиться о том, что именно оно представляет, просто оно представляет все, что будет дальше.

Вышеупомянутое является небольшим упрощением - get_response вызываемый для последнего промежуточного программного обеспечения в цепочке будет не фактическим представлением, а скорее методом-оболочкой из обработчика, который заботится о применении промежуточного программного обеспечения представления , вызове представления с соответствующими аргументами URL-адреса и применении шаблона промежуточное ПО для ответов и исключений .

Промежуточное ПО может поддерживать только синхронный Python (по умолчанию), только асинхронный Python или и то, и другое. См. Раздел « Асинхронная поддержка», чтобы узнать, как рекламировать то, что вы поддерживаете, и узнать, какой тип запроса вы получаете.

Промежуточное ПО может находиться где угодно на вашем пути Python.

Активация промежуточного ПО ¶

Чтобы активировать компонент промежуточного программного обеспечения, добавьте его в MIDDLEWARE список в настройках Django.

В MIDDLEWARE каждый компонент промежуточного программного обеспечения представлен строкой: полный путь Python к классу или имени функции фабрики промежуточного программного обеспечения. Например, вот значение по умолчанию, созданное :django-admin startproject

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',
]

Установка Django не требует промежуточного программного обеспечения - MIDDLEWARE может быть пустым, если хотите, - но настоятельно рекомендуется, чтобы вы хотя бы использовали CommonMiddleware .

Порядок MIDDLEWARE имеет значение, потому что промежуточное программное обеспечение может зависеть от другого промежуточного программного обеспечения. Например, AuthenticationMiddleware сохраняет аутентифицированного пользователя в сеансе; следовательно, он должен работать после SessionMiddleware . См. Раздел Упорядочивание промежуточного программного обеспечения для некоторых общих советов по упорядочиванию классов промежуточного программного обеспечения Django.

Порядок и наслоение промежуточного программного обеспечения ¶

На этапе запроса, перед вызовом представления, Django применяет промежуточное ПО в том порядке, в котором оно определено MIDDLEWARE , сверху вниз.

Вы можете думать об этом как о луковице: каждый класс промежуточного программного обеспечения - это «слой», который обертывает представление, которое находится в ядре лука. Если запрос проходит через все уровни луковицы (каждый из них вызывает get_response передачу запроса на следующий уровень), вплоть до представления в ядре, ответ затем пройдет через каждый уровень (в обратном порядке) на путь обратно.

Если один из слоев решает выполнить короткое замыкание и вернуть ответ, даже не вызывая его get_response , ни один из слоев лука внутри этого слоя (включая представление) не увидит запрос или ответ. Ответ будет возвращен только через те же уровни, через которые прошел запрос.

Другие хуки промежуточного ПО ¶

Помимо базового шаблона промежуточного программного обеспечения запроса / ответа, описанного ранее, вы можете добавить три других специальных метода в промежуточное программное обеспечение на основе классов:

Работа с потоковыми ответами ¶

В отличие от HttpResponse , StreamingHttpResponse не имеет content атрибута. В результате промежуточное ПО больше не может предполагать, что все ответы будут иметь content атрибут. Если им нужен доступ к контенту, они должны протестировать потоковые ответы и соответствующим образом скорректировать свое поведение:

if response.streaming:
    response.streaming_content = wrap_streaming_content(response.streaming_content)
else:
    response.content = alter_content(response.content)

def wrap_streaming_content(content):
    for chunk in content:
        yield alter_content(chunk)

Обработка исключений ¶

Django автоматически преобразует исключения, вызванные представлением или промежуточным программным обеспечением, в соответствующий HTTP-ответ с кодом состояния ошибки. Некоторые исключения преобразуются в коды состояния 4xx, в то время как неизвестное исключение преобразуется в код состояния 500.

Это преобразование происходит до и после каждого промежуточного программного обеспечения (вы можете думать о нем как о тонкой пленке между каждым слоем луковицы), так что каждое промежуточное программное обеспечение всегда может рассчитывать на получение какого-либо ответа HTTP от вызова его get_response вызываемого. Промежуточному программному обеспечению не нужно беспокоиться о переносе своего вызова get_response в a try/except и обработке исключения, которое могло быть вызвано более поздним промежуточным программным обеспечением или представлением. Даже если следующее промежуточное ПО в цепочке Http404 вызовет исключение, например, ваше промежуточное ПО не увидит этого исключения; вместо этого он получит HttpResponse объект с status_code 404.

Асинхронная поддержка ¶

Промежуточное ПО может поддерживать любую комбинацию синхронных и асинхронных запросов. Django адаптирует запросы в соответствии с требованиями промежуточного программного обеспечения, если оно не может поддерживать оба, но со снижением производительности.

По умолчанию Django предполагает, что ваше промежуточное ПО способно обрабатывать только синхронные запросы. Чтобы изменить эти предположения, установите следующие атрибуты в функции или классе фабрики промежуточного программного обеспечения:

• sync_capable - логическое значение, указывающее, может ли промежуточное ПО обрабатывать синхронные запросы. По умолчанию True .
• async_capable - логическое значение, указывающее, может ли промежуточное ПО обрабатывать асинхронные запросы. По умолчанию False .

Если в вашем промежуточном программном обеспечении есть оба и , то Django передаст ему запрос без его преобразования. В этом случае вы можете определить, будет ли ваше промежуточное ПО получать асинхронные запросы, проверив, является ли переданный вам объект функцией сопрограммы, используя .sync_capable = True async_capable = True get_response asyncio.iscoroutinefunction()

django.utils.decorators Модуль содержит sync_only_middleware() , async_only_middleware() и sync_and_async_middleware() декоратор , которые позволяют применять эти флаги промежуточных уровня заводских функций.

Возвращаемый вызываемый объект должен соответствовать синхронному или асинхронному характеру get_response метода. Если у вас асинхронный get_response , вы должны вернуть функцию сопрограммы ( ).async def

process_view , process_template_response и process_exception методы, если они предусмотрены, также должны быть адаптированы для соответствия режиму синхронизации / асинхронности. Однако Django индивидуально адаптирует их по мере необходимости, если вы этого не сделаете, что приведет к дополнительному снижению производительности.

Вот пример того, как создать функцию промежуточного программного обеспечения, которая поддерживает оба:

import asyncio
from django.utils.decorators import sync_and_async_middleware

@sync_and_async_middleware
def simple_middleware(get_response):
    # One-time configuration and initialization goes here.
    if asyncio.iscoroutinefunction(get_response):
        async def middleware(request):
            # Do something here!
            response = await get_response(request)
            return response

    else:
        def middleware(request):
            # Do something here!
            response = get_response(request)
            return response

    return middleware

Обновление промежуточного ПО в стиле до Django 1.10 ¶

класс django.utils.deprecation.MiddlewareMixin¶

Django django.utils.deprecation.MiddlewareMixin упрощает создание классов промежуточного программного обеспечения, совместимых как MIDDLEWARE со старыми MIDDLEWARE_CLASSES , так и со старыми , и поддерживает синхронные и асинхронные запросы. Все классы промежуточного программного обеспечения, включенные в Django, совместимы с обеими настройками.

Миксин предоставляет __init__() метод, который требует get_response аргумента и сохраняет его в self.get_response .

__call__() Метод:

1. Звонки self.process_request(request) (если определены).
2. Вызывает, self.get_response(request) чтобы получить ответ от более позднего промежуточного программного обеспечения и представления.
3. Звонки (если определены).self.process_response(request, response)
4. Возвращает ответ.

Если используется с MIDDLEWARE_CLASSES , __call__() метод никогда не будет использоваться; Django звонит process_request() и process_response() напрямую.

В большинстве случаев наследования от этого миксина будет достаточно, чтобы сделать промежуточное ПО старого стиля совместимым с новой системой с достаточной обратной совместимостью. Новая семантика короткого замыкания будет безвредной или даже полезной для существующего промежуточного программного обеспечения. В некоторых случаях класс промежуточного программного обеспечения может нуждаться в некоторых изменениях, чтобы приспособиться к новой семантике.

Это поведенческие различия между использованием MIDDLEWARE и MIDDLEWARE_CLASSES :

1. В соответствии с этим у MIDDLEWARE_CLASSES каждого промежуточного программного обеспечения всегда будет process_response вызываться его метод, даже если более раннее промежуточное программное обеспечение завершило работу, вернув ответ от своего process_request метода. В MIDDLEWARE нижней части промежуточное ПО ведет себя больше как луковица: уровни, через которые проходит ответ на выходе, являются теми же уровнями, которые видели запрос на входе. Если промежуточное ПО выполняет короткое замыкание, только это промежуточное ПО и те, которые были перед ним, MIDDLEWARE будут увидеть ответ.
2. Под MIDDLEWARE_CLASSES , process_exception применяются для исключения поднятого из промежуточного программного process_request метода. Под MIDDLEWARE , process_exception применяется только к исключениям, вызванным из представления (или из render метода a TemplateResponse ). Исключения, вызванные промежуточным программным обеспечением, преобразуются в соответствующий HTTP-ответ и затем передаются следующему промежуточному программному обеспечению.
3. Ниже MIDDLEWARE_CLASSES , если process_response метод вызывает исключение, process_response методы всего более раннего промежуточного программного обеспечения пропускаются и всегда возвращается ответ HTTP (даже если возникшее исключение было, например, ошибкой ). Ниже исключение, вызванное промежуточным программным обеспечением, будет немедленно преобразовано в соответствующий HTTP-ответ, а затем следующее промежуточное программное обеспечение в строке увидит этот ответ. Промежуточное ПО никогда не пропускается из-за того, что промежуточное ПО вызывает исключение.500 Internal Server Error Http404 MIDDLEWARE