Обработка условного отображения

Клиенты HTTP могут отправлять ряд заголовков, чтобы сообщить серверу о копиях ресурса, которые они уже видели. Это обычно используется при получении веб-страницы (используя HTTP GET запрос), чтобы избежать отправки всех данных для чего-то, что клиент уже получил. Однако те же заголовки могут использоваться для всех методов HTTP (POST, PUT, DELETE, и т. д.).

Для каждой страницы (ответа), которую Django отправляет обратно из представления, она может предоставить два HTTP-заголовка: заголовок ETag и заголовок Last-Modified. Эти заголовки являются необязательными в ответах HTTP. Их можно установить в вашей функции представления, или вы можете положиться на middleware ConditionalGetMiddleware, чтобы установить заголовок ETag.

Когда клиент в следующий раз запросит тот же ресурс, он может отправить заголовок, такой как If-Modified-Since или If-Unmodified-Since, содержащий дату последнего времени изменения, или If-Match или If-None-Match, содержащий последнее ETag. Если текущая версия страницы соответствует ETag, отправленному клиентом, или если ресурс не был изменён, может быть отправлен код состояния 304, вместо полного ответа, сообщая клиенту, что ничего не изменилось. В зависимости от заголовка, если страница была изменена или не соответствует ETag, отправленному клиентом, может быть возвращён код состояния 412 (Ошибка условия).

Когда вам требуется более тонкий контроль, вы можете использовать функции условной обработки на уровне представления.

Декоратор condition

Иногда (на самом деле, довольно часто) вы можете создавать функции для быстрого вычисления значения ETag или последнего времени изменения ресурса, **без** необходимости выполнять все вычисления, необходимые для построения полного представления. Django затем может использовать эти функции, чтобы предоставить вариант «быстрого выхода» для обработки представления. Сообщить клиенту, что содержимое не изменялось с момента последнего запроса.

Эти две функции передаются в качестве параметров декоратору django.views.decorators.http.condition. Этот декоратор использует две функции (вам нужна только одна, если вы не можете вычислить обе величины легко и быстро), чтобы определить, соответствуют ли заголовки в запросе HTTP заголовкам ресурса. Если они не совпадают, новая копия ресурса должна быть вычислена, и вызывается ваше обычное представление.

Подпись декоратора condition выглядит следующим образом:

condition(etag_func=None, last_modified_func=None)

Две функции для вычисления ETag и последнего времени изменения будут переданы объект входящего запроса request и те же параметры, в том же порядке, что и функция представления, которую они помогают обернуть. Функция, переданная last_modified_func, должна возвращать стандартное значение datetime, указывающее последнее время изменения ресурса, или None, если ресурс не существует. Функция, переданная декоратору etag, должна возвращать строку, представляющую ETag ресурса, или None, если он не существует.

Декоратор устанавливает заголовки ETag и Last-Modified в ответе, если они ещё не установлены представлением, и если метод запроса безопасен (GET или HEAD).

Использование этой функции наиболее эффективно объясняется на примере. Предположим, у вас есть такая пара моделей, представляющая небольшую систему блога:

import datetime
from django.db import models


class Blog(models.Model): ...


class Entry(models.Model):
    blog = models.ForeignKey(Blog, on_delete=models.CASCADE)
    published = models.DateTimeField(default=datetime.datetime.now)
    ...

Если главная страница, отображающая последние записи блога, изменяется только при добавлении новой записи в блог, вы можете очень быстро вычислить время последнего изменения. Вам нужно самое последнее published для каждой записи, связанной с этим блогом. Один из способов сделать это:

def latest_entry(request, blog_id):
    return Entry.objects.filter(blog=blog_id).latest("published").published

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

from django.views.decorators.http import condition


@condition(last_modified_func=latest_entry)
def front_page(request, blog_id): ...

Сокращения для вычисления только одного значения

Как общее правило, если вы можете предоставить функции для вычисления оба ETag и время последнего изменения, вы должны это сделать. Вы не знаете, какие заголовки любой данный клиент HTTP вам отправит, поэтому будьте готовы обработать оба. Однако иногда вычислять только одно значение легче, и Django предоставляет декораторы, которые обрабатывают только ETag или только вычисления времени последнего изменения.

Декораторы django.views.decorators.http.etag и django.views.decorators.http.last_modified принимают те же типы функций, что и декоратор condition. Их подписи следующие:

etag(etag_func)
last_modified(last_modified_func)

Мы могли бы переписать предыдущий пример, использующий только функцию последнего изменения, используя один из этих декораторов:

@last_modified(latest_entry)
def front_page(request, blog_id): ...

…или:

def front_page(request, blog_id): ...


front_page = last_modified(latest_entry)(front_page)

Используйте condition при проверке обоих условий

Некоторым может показаться более удобным попробовать объединить декораторы etag и last_modified если вы хотите проверить оба условия. Однако это приведет к неправильному поведению.

# Bad code. Don't do this!
@etag(etag_func)
@last_modified(last_modified_func)
def my_view(request): ...


# End of bad code.

Первый декоратор ничего не знает о втором и может ответить, что ответ не изменён, даже если второй декоратор определит обратное. Декоратор condition одновременно использует обе функции обратного вызова, чтобы определить правильное действие.

Использование декораторов с другими методами HTTP

Декоратор condition полезен не только для запросов GET и HEAD (запросы HEAD такие же, как GET в этой ситуации). Он также может быть использован для проверки запросов POST, PUT и DELETE. В этих ситуациях идея не в том, чтобы вернуть ответ «не изменён», а в том, чтобы сообщить клиенту, что ресурс, который он пытается изменить, был изменён в то же время.

Например, рассмотрим следующий обмен между клиентом и сервером:

1. Клиент запрашивает /foo/.
2. Сервер отвечает некоторым содержимым с ETag "abcd1234".
3. Клиент отправляет HTTP-запрос PUT на /foo/ для обновления ресурса. Он также отправляет заголовок If-Match: "abcd1234" для указания версии, которую он пытается обновить.
4. Сервер проверяет, изменился ли ресурс, вычисляя ETag так же, как и для запроса GET (используя ту же функцию). Если ресурс изменился, он вернёт код состояния 412, что означает «условие не выполнено».
5. Клиент отправляет запрос GET на /foo/, после получения ответа 412, чтобы получить обновлённую версию содержимого перед обновлением.

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

Сравнение с условной обработкой на уровне middleware

Django предоставляет обработку условных GET через django.middleware.http.ConditionalGetMiddleware. Хотя она подходит для многих ситуаций, middleware имеет ограничения для расширенного использования:

• Она применяется глобально ко всем представлениям в вашем проекте.
• Она не избавляет вас от генерации ответа, что может быть дорогостоящим.
• Она подходит только для HTTP-запросов GET.

Вы должны выбрать наиболее подходящий инструмент для вашей конкретной проблемы. Если у вас есть способ быстро вычислить ETag и время изменения, и какое-то представление занимает много времени для генерации содержимого, вы должны рассмотреть использование декоратора condition, описанного в этом документе. Если всё уже работает достаточно быстро, придерживайтесь использования middleware, и объём сетевого трафика, отправленного клиентам, всё равно будет уменьшен, если представление не изменилось.