Объекты запроса и ответа

Краткий обзор

Django использует объекты запроса и ответа для передачи состояния через систему.

При запросе страницы Django создает объект HttpRequest, содержащий метаданные о запросе. Затем Django загружает соответствующий вид, передавая объект HttpRequest в качестве первого аргумента функции представления. Каждое представление отвечает за возврат объекта HttpResponse.

В данном документе описываются API для объектов HttpRequest и HttpResponse, которые определены в модуле django.http.

HttpRequest объекты

class HttpRequest [source]

Атрибуты

Все атрибуты считаются только для чтения, если не указано иное.

HttpRequest.scheme

Строка, представляющая схему запроса (http или https обычно).

HttpRequest.body

Необработанное тело HTTP-запроса в виде строки байтов. Это полезно для обработки данных нестандартными способами, отличными от обычных HTML-форм: бинарные изображения, XML-загрузка и т.д. Для обработки обычных данных форм используйте HttpRequest.POST.

Вы также можете читать из HttpRequest с помощью интерфейса типа файла. См. HttpRequest.read().

HttpRequest.path

Строка, представляющая полный путь к запрашиваемой странице, без схемы или домена.

Пример: "/music/bands/the_beatles/"

HttpRequest.path_info

В некоторых конфигурациях веб-сервера часть URL после имени хоста разделяется на часть префикса скрипта и часть path info. Атрибут path_info всегда содержит часть path info пути, независимо от используемого веб-сервера. Использование этого вместо path может сделать ваш код более переносимым между тестовыми и рабочими серверами.

Например, если WSGIScriptAlias для вашего приложения установлено как "/minfo", тогда path может быть "/minfo/music/bands/the_beatles/", и path_info будет "/music/bands/the_beatles/".

HttpRequest.method

Строка, представляющая HTTP-метод, используемый в запросе. Гарантируется, что он будет в верхнем регистре. Например:

if request.method == 'GET':
    do_something()
elif request.method == 'POST':
    do_something_else()

HttpRequest.encoding

Строка, представляющая текущее кодирование, используемое для декодирования данных отправки формы (или None, что означает, что используется настройка DEFAULT_CHARSET). Вы можете записать в этот атрибут, чтобы изменить кодировку, используемую при доступе к данным формы. Все последующие обращения к атрибутам (например, чтение из GET или POST) будут использовать новое значение encoding. Полезно, если данные формы не в кодировке DEFAULT_CHARSET.

HttpRequest.content_type

Строка, представляющая MIME-тип запроса, полученная из заголовка CONTENT_TYPE.

HttpRequest.content_params

Словарь пар «ключ-значение», включенных в заголовок CONTENT_TYPE.

HttpRequest.GET

Объект, подобный словарю, содержащий все переданные параметры GET. См. документацию по QueryDict ниже.

HttpRequest.POST

Объект, подобный словарю, содержащий все переданные параметры POST, при условии, что запрос содержит данные формы. См. документацию по QueryDict ниже. Если вам нужно получить необработанные или не связанные с формой данные, отправленные в запросе, обращайтесь к атрибуту HttpRequest.body вместо этого.

Возможно, что запрос может поступить по POST с пустым словарем POST — если, например, форма запрошена через HTTP-метод POST, но не содержит данных формы. Поэтому не следует использовать if request.POST для проверки использования метода POST; вместо этого используйте if request.method == "POST" (см. HttpRequest.method).

POST не включает информацию о загрузке файлов. См. FILES.

HttpRequest.COOKIES

Словарь, содержащий все cookie. Ключи и значения — строки.

HttpRequest.FILES

Объект, подобный словарю, содержащий все загруженные файлы. Каждый ключ в FILES является name из <input type="file" name=""> Каждый элемент в FILES является объектом UploadedFile.

См. Управление файлами для получения дополнительной информации.

FILES будет содержать данные только в том случае, если метод запроса был POST и <form>, отправленный в запрос, содержал enctype="multipart/form-data". В противном случае FILES будет пустым объектом, подобным словарю.

HttpRequest.META

Словарь, содержащий все доступные HTTP-заголовки. Доступные заголовки зависят от клиента и сервера, но вот некоторые примеры:

• CONTENT_LENGTH — Длина тела запроса (как строка).
• CONTENT_TYPE — MIME-тип тела запроса.
• HTTP_ACCEPT — Допустимые типы контента для ответа.
• HTTP_ACCEPT_ENCODING — Допустимые кодировки для ответа.
• HTTP_ACCEPT_LANGUAGE — Допустимые языки для ответа.
• HTTP_HOST — Заголовок HTTP Host, отправленный клиентом.
• HTTP_REFERER — Ссылка на предыдущую страницу, если есть.
• HTTP_USER_AGENT — Строка пользовательского агента клиента.
• QUERY_STRING — Строка запроса как единая (необработанная) строка.
• REMOTE_ADDR — IP-адрес клиента.
• REMOTE_HOST — Имя хоста клиента.
• REMOTE_USER — Пользователь, аутентифицированный веб-сервером, если таковой имеется.
• REQUEST_METHOD — Строка типа "GET" или "POST".
• SERVER_NAME — Имя хоста сервера.
• SERVER_PORT — Порт сервера (как строка).

За исключением CONTENT_LENGTH и CONTENT_TYPE, как указано выше, все HTTP-заголовки в запросе преобразуются в ключи META путем преобразования всех символов в верхний регистр, замены всех тире на подчеркивания и добавления префикса HTTP_ к имени. Например, заголовок с именем X-Bender будет сопоставлен с ключом META HTTP_X_BENDER.

Обратите внимание, что runserver удаляет все заголовки с подчеркиванием в имени, поэтому вы их не увидите в META. Это предотвращает подделку заголовков на основе неоднозначности между подчеркиваниями и дефисами, которые оба нормализуются до подчеркиваний в переменных среды WSGI. Это поведение соответствует поведению веб-серверов, таких как Nginx и Apache 2.4+.

HttpRequest.resolver_match

Экземпляр ResolverMatch, представляющий разрешенный URL. Этот атрибут устанавливается только после разрешения URL, что означает, что он доступен во всех представлениях, но не в middleware, которые выполняются до разрешения URL (хотя вы можете использовать его в process_view()).

Атрибуты, установленные кодом приложения

Django не устанавливает эти атрибуты сам, но использует их, если они установлены вашим приложением.

HttpRequest.current_app

Тег шаблона url будет использовать его значение в качестве параметра current_app для reverse().

HttpRequest.urlconf

Это будет использоваться в качестве корневого URLconf для текущего запроса, переопределяя настройку ROOT_URLCONF. Подробности см. в Как Django обрабатывает запрос.

urlconf может быть установлено в None для отмены всех изменений, внесённых предыдущим средством обработки, и возврата к использованию ROOT_URLCONF.

Атрибуты, установленные средствами обработки

Некоторые средства обработки, включённые в приложения contrib Django, устанавливают атрибуты в запросе. Если вы не видите атрибут в запросе, убедитесь, что соответствующий класс средства обработки указан в MIDDLEWARE.

HttpRequest.session

Из SessionMiddleware: Чтимый и записываемый, подобный словарю объект, представляющий текущую сессию.

HttpRequest.site

Из CurrentSiteMiddleware: Экземпляр Site или RequestSite, как возвращает get_current_site(), представляющий текущий сайт.

HttpRequest.user

Из AuthenticationMiddleware: Экземпляр AUTH_USER_MODEL, представляющий текущего авторизованного пользователя. Если пользователь не авторизован, user будет установлен в экземпляр AnonymousUser. Отличить их можно с помощью is_authenticated, как показано ниже:

if request.user.is_authenticated:
    ... # Do something for logged-in users.
else:
    ... # Do something for anonymous users.

Методы

HttpRequest.get_host() [source]

Возвращает хост-имя источника запроса, используя данные из HTTP_X_FORWARDED_HOST (если включено USE_X_FORWARDED_HOST) и HTTP_HOST заголовков, в этом порядке. Если они не предоставляют значение, метод использует комбинацию SERVER_NAME и SERVER_PORT, как подробно описано в PEP 3333.

Пример: "127.0.0.1:8000"

Примечание

Метод get_host() может давать сбой, когда хост находится за несколькими прокси-серверами. Одним из решений является использование средства обработки для переписывания заголовков прокси, как в следующем примере:

from django.utils.deprecation import MiddlewareMixin

class MultipleProxyMiddleware(MiddlewareMixin):
    FORWARDED_FOR_FIELDS = [
        'HTTP_X_FORWARDED_FOR',
        'HTTP_X_FORWARDED_HOST',
        'HTTP_X_FORWARDED_SERVER',
    ]

    def process_request(self, request):
        """
        Rewrites the proxy headers so that only the most
        recent proxy is used.
        """
        for field in self.FORWARDED_FOR_FIELDS:
            if field in request.META:
                if ',' in request.META[field]:
                    parts = request.META[field].split(',')
                    request.META[field] = parts[-1].strip()

Это средство обработки должно быть размещено перед другими средствами обработки, которые полагаются на значение get_host() – например, CommonMiddleware или CsrfViewMiddleware.

HttpRequest.get_port() [source]

Возвращает исходный порт запроса, используя данные из HTTP_X_FORWARDED_PORT (если включен USE_X_FORWARDED_PORT) и SERVER_PORT META переменных, в этом порядке.

HttpRequest.get_full_path() [source]

Возвращает path, плюс добавленную строку запроса, если применимо.

Пример: "/music/bands/the_beatles/?print=true"

HttpRequest.get_full_path_info() [source]

Новое в Django 2.1.

Подобно get_full_path(), но использует path_info вместо path.

Пример: "/minfo/music/bands/the_beatles/?print=true"

HttpRequest.build_absolute_uri(location=None) [source]

Возвращает абсолютную форму URI для location. Если местоположение не указано, местоположение будет установлено в request.get_full_path().

Если местоположение уже является абсолютным URI, оно не будет изменено. В противном случае абсолютный URI строится с использованием переменных сервера, доступных в этом запросе. Например:

>>> request.build_absolute_uri()
'https://example.com/music/bands/the_beatles/?print=true'
>>> request.build_absolute_uri('/bands/')
'https://example.com/bands/'
>>> request.build_absolute_uri('https://example2.com/bands/')
'https://example2.com/bands/'

Примечание

Смешивание HTTP и HTTPS на одном сайте не рекомендуется, поэтому build_absolute_uri() всегда будет генерировать абсолютный URI со схемой, совпадающей со схемой текущего запроса. Если вам нужно перенаправить пользователей на HTTPS, лучше всего настроить ваш веб-сервер на перенаправление всего трафика HTTP на HTTPS.

HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None) [source]

Возвращает значение cookie для подписанной cookie или вызывает исключение django.core.signing.BadSignature если подпись больше недействительна. Если вы предоставите аргумент default, исключение будет подавлено, и вместо него будет возвращено это значение по умолчанию.

Необязательный аргумент salt может быть использован для дополнительной защиты от атак с перебором паролей на ваш секретный ключ. Если он указан, аргумент max_age будет проверено на соответствие подписанному временной метке, прикрепленной к значению cookie, чтобы убедиться, что cookie не старше max_age секунд.

Например:

>>> request.get_signed_cookie('name')
'Tony'
>>> request.get_signed_cookie('name', salt='name-salt')
'Tony' # assuming cookie was set using the same salt
>>> request.get_signed_cookie('nonexistent-cookie')
...
KeyError: 'nonexistent-cookie'
>>> request.get_signed_cookie('nonexistent-cookie', False)
False
>>> request.get_signed_cookie('cookie-that-was-tampered-with')
...
BadSignature: ...
>>> request.get_signed_cookie('name', max_age=60)
...
SignatureExpired: Signature age 1677.3839159 > 60 seconds
>>> request.get_signed_cookie('name', False, max_age=60)
False

См. криптографическое подписание для получения дополнительной информации.

HttpRequest.is_secure() [source]

Возвращает True, если запрос защищён; то есть, если он был выполнен с использованием HTTPS.

HttpRequest.is_ajax() [source]

Возвращает True, если запрос был выполнен с помощью XMLHttpRequest, проверяя HTTP_X_REQUESTED_WITH заголовок на наличие строки 'XMLHttpRequest'. Большинство современных JavaScript библиотек отправляют этот заголовок. Если вы пишете свой XMLHttpRequest вызов (на стороне браузера), вам необходимо установить этот заголовок вручную, если вы хотите, чтобы is_ajax() работал.

Если ответ зависит от того, был ли он запрошен через AJAX, и вы используете какой-либо кеширование, например, кеширование Django cache middleware, вы должны добавить декоратор vary_on_headers('X-Requested-With') к представлению, чтобы ответы были правильно кэшированы.

HttpRequest.read(size=None) [source]

HttpRequest.readline() [source]

HttpRequest.readlines() [source]

HttpRequest.__iter__() [source]

Методы, реализующие интерфейс типа файла для чтения из объекта HttpRequest. Это позволяет потреблять входящий запрос потоковым способом. Типичное применение — обработка большого XML-payload с итерационным парсером без построения всего XML-дерева в памяти.

Благодаря этому стандартному интерфейсу объект HttpRequest может быть передан напрямую XML-парсеру, например, ElementTree:

import xml.etree.ElementTree as ET
for element in ET.iterparse(request):
    process(element)

QueryDict объекты

class QueryDict [source]

В объекте HttpRequest, атрибуты GET и POST являются экземплярами django.http.QueryDict, — словареподобного класса, настроенного для обработки нескольких значений для одного и того же ключа. Это необходимо, потому что некоторые элементы HTML-форм, в частности <select multiple>, передают несколько значений для одного ключа.

Объекты QueryDict в request.POST и request.GET будут неизменяемыми при обращении в обычном цикле запроса/ответа. Чтобы получить изменяемую копию, необходимо использовать QueryDict.copy().

Методы

QueryDict реализует все стандартные методы словаря, так как является подклассом словаря. Исключения описаны здесь:

QueryDict.__init__(query_string=None, mutable=False, encoding=None) [source]

Инициализирует объект QueryDict на основе query_string.

>>> QueryDict('a=1&a=2&c=3')
<QueryDict: {'a': ['1', '2'], 'c': ['3']}>

Если query_string не передан, получившийся объект QueryDict будет пустым (не будет иметь ключей или значений).

Большинство встречающихся вам объектов QueryDict, и, в частности, те, что в request.POST и request.GET, будут неизменяемыми. Если вы создаёте его самостоятельно, вы можете сделать его изменяемым, передав mutable=True в его метод __init__().

Строки для установки ключей и значений будут преобразованы из encoding в str. Если encoding не задан, он по умолчанию равен DEFAULT_CHARSET.

classmethod QueryDict.fromkeys(iterable, value='', mutable=False, encoding=None) [source]

Создаёт новый объект QueryDict с ключами из iterable и каждым значением равным value. Например:

>>> QueryDict.fromkeys(['a', 'a', 'b'], value='val')
<QueryDict: {'a': ['val', 'val'], 'b': ['val']}>

QueryDict.__getitem__(key)

Возвращает значение для данного ключа. Если ключ имеет более одного значения, возвращает последнее значение. Вызывает исключение django.utils.datastructures.MultiValueDictKeyError если ключ не существует. (Это подкласс стандартного исключения Python KeyError, поэтому можно ограничиться перехватом исключения KeyError.)

QueryDict.__setitem__(key, value) [source]

Устанавливает заданный ключ в [value] (список, содержащий единственный элемент value). Обратите внимание, что этот и другие функции словаря, которые имеют побочные эффекты, могут быть вызваны только для изменяемого объекта QueryDict (например, созданного с помощью QueryDict.copy()).

QueryDict.__contains__(key)

Возвращает True если заданный ключ установлен. Это позволяет выполнять, например, if "foo" in request.GET.

QueryDict.get(key, default=None)

Использует ту же логику, что и __getitem__(), с крючком для возврата значения по умолчанию, если ключ не существует.

QueryDict.setdefault(key, default=None) [source]

Аналогично dict.setdefault(), за исключением того, что внутренне использует __setitem__().

QueryDict.update(other_dict)

Принимает либо QueryDict , либо словарь. Подобно dict.update(), за исключением того, что добавляет к текущим элементам словаря, а не заменяет их. Например:

>>> q = QueryDict('a=1', mutable=True)
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # returns the last
'2'

QueryDict.items()

Аналогично dict.items(), за исключением того, что использует ту же логику последнего значения, что и __getitem__(), и возвращает объект-итератор вместо объекта-представления. Например:

>>> q = QueryDict('a=1&a=2&a=3')
>>> list(q.items())
[('a', '3')]

QueryDict.values()

Аналогично dict.values(), за исключением того, что использует ту же логику последнего значения, что и __getitem__(), и возвращает итератор вместо объекта-представления. Например:

>>> q = QueryDict('a=1&a=2&a=3')
>>> list(q.values())
['3']

Кроме того, объект QueryDict имеет следующие методы:

QueryDict.copy() [source]

Возвращает копию объекта с помощью copy.deepcopy(). Эта копия будет изменяемой, даже если исходная не была.

QueryDict.getlist(key, default=None)

Возвращает список данных с запрошенным ключом. Возвращает пустой список, если ключ не существует и значение по умолчанию не было предоставлено. Гарантируется, что возвращаемое значение — список, если значение по умолчанию не является списком.

QueryDict.setlist(key, list_) [source]

Устанавливает заданный ключ в list_ (в отличие от __setitem__()).

QueryDict.appendlist(key, item) [source]

Добавляет элемент в внутренний список, связанный с ключом.

QueryDict.setlistdefault(key, default_list=None) [source]

Аналогично setdefault(), за исключением того, что принимает список значений вместо одного значения.

QueryDict.lists()

Аналогично items(), за исключением того, что включает все значения, как список, для каждого элемента словаря. Например:

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]

QueryDict.pop(key) [source]

Возвращает список значений для заданного ключа и удаляет их из словаря. Вызывает исключение KeyError если ключ не существует. Например:

>>> q = QueryDict('a=1&a=2&a=3', mutable=True)
>>> q.pop('a')
['1', '2', '3']

QueryDict.popitem() [source]

Удаляет произвольный элемент словаря (поскольку нет понятия порядка) и возвращает кортеж из двух значений, содержащий ключ и список всех значений для ключа. Вызывает исключение KeyError при вызове на пустом словаре. Например:

>>> q = QueryDict('a=1&a=2&a=3', mutable=True)
>>> q.popitem()
('a', ['1', '2', '3'])

QueryDict.dict()

Возвращает представление dict объекта QueryDict. Для каждой пары (ключ, список) в QueryDict, dict будет содержать (ключ, элемент), где элемент — один из элементов списка, используя ту же логику, что и QueryDict.__getitem__():

>>> q = QueryDict('a=1&a=3&a=5')
>>> q.dict()
{'a': '5'}

QueryDict.urlencode(safe=None) [source]

Возвращает строку данных в формате строки запроса. Например:

>>> q = QueryDict('a=2&b=3&b=5')
>>> q.urlencode()
'a=2&b=3&b=5'

Используйте параметр safe для передачи символов, не требующих кодирования. Например:

>>> q = QueryDict(mutable=True)
>>> q['next'] = '/a&b/'
>>> q.urlencode(safe='/')
'next=/a%26b/'

HttpResponse объекты

class HttpResponse [source]

В отличие от объектов HttpRequest, которые создаются автоматически Django, объекты HttpResponse являются вашей ответственностью. Каждый написанный вами вид отвечает за создание, заполнение и возврат объекта HttpResponse.

Класс HttpResponse находится в модуле django.http.

Использование

Передача строк

Типичное использование — передача содержимого страницы в виде строки конструктору HttpResponse:

>>> from django.http import HttpResponse
>>> response = HttpResponse("Here's the text of the Web page.")
>>> response = HttpResponse("Text only, please.", content_type="text/plain")

Но если вы хотите добавлять содержимое по частям, вы можете использовать response как объект-подобный файлу:

>>> response = HttpResponse()
>>> response.write("<p>Here's the text of the Web page.</p>")
>>> response.write("<p>Here's another paragraph.</p>")

Передача итераторов

Наконец, вы можете передать HttpResponse итератор вместо строк. HttpResponse немедленно использует итератор, сохраняет его содержимое в виде строки и отбрасывает его. Объекты с методом close(), такими как файлы и генераторы, немедленно закрываются.

Если вам нужно, чтобы ответ передавался по потокам из итератора клиенту, вы должны использовать класс StreamingHttpResponse вместо этого.

Установка полей заголовков

Чтобы установить или удалить поле заголовка в ответе, обратитесь к нему как к словарю:

>>> response = HttpResponse()
>>> response['Age'] = 120
>>> del response['Age']

Обратите внимание, что в отличие от словаря, del не вызывает KeyError если поле заголовка не существует.

Для установки полей заголовков Cache-Control и Vary рекомендуется использовать методы patch_cache_control() и patch_vary_headers() из модуля django.utils.cache, так как эти поля могут иметь несколько значений, разделённых запятыми. Методы «patch» гарантируют, что другие значения, добавленные, например, посредством промежуточного слоя, не будут удалены.

Поля HTTP-заголовков не могут содержать символы новой строки. Попытка установить поле заголовка, содержащее символ новой строки (CR или LF), вызовет BadHeaderError

Инструктирование браузера обрабатывать ответ как вложение файла

Чтобы сказать браузеру обрабатывать ответ как вложение файла, используйте аргумент content_type и установите заголовок Content-Disposition. Например, вот как вы можете вернуть электронную таблицу Microsoft Excel:

>>> response = HttpResponse(my_data, content_type='application/vnd.ms-excel')
>>> response['Content-Disposition'] = 'attachment; filename="foo.xls"'

Заголовок Content-Disposition не является специфичным для Django, но легко забыть его синтаксис, поэтому мы включили его здесь.

Атрибуты

HttpResponse.content

Строка байтов, представляющая содержимое, закодированная из строки при необходимости.

HttpResponse.charset

Строка, обозначающая кодировку символов, в которой будет закодирован ответ. Если она не задана при создании, она извлекается из HttpResponse, а если это невозможно, используется значение настройки DEFAULT_CHARSET.

HttpResponse.status_code

Код состояния HTTP для ответа.

Если reason_phrase не задан явно, изменение значения status_code вне конструктора также изменит значение reason_phrase.

HttpResponse.reason_phrase

Фраза причины HTTP для ответа. Она использует стандартные фразы причин HTTP.

Если не задан явно, reason_phrase определяется значением status_code.

HttpResponse.streaming

Это всегда False.

Этот атрибут существует, чтобы промежуточные слои могли по-разному обрабатывать потоковые ответы.

HttpResponse.closed

True если ответ был закрыт.

Методы

HttpResponse.__init__(content='', content_type=None, status=200, reason=None, charset=None) [source]

Инициализирует объект HttpResponse с заданным содержимым страницы и типом содержимого.

content должен быть итератором или строкой. Если это итератор, он должен возвращать строки, и эти строки будут объединены для формирования содержимого ответа. Если это не итератор или строка, при обращении к нему он будет преобразован в строку.

content_type — тип MIME, который дополнительно может включать кодировку набора символов и используется для заполнения HTTP-заголовка Content-Type. Если не указан, он формируется по настройкам DEFAULT_CONTENT_TYPE и DEFAULT_CHARSET, по умолчанию: “text/html; charset=utf-8”.

status — код состояния HTTP для ответа.

reason — фраза HTTP-ответа. Если не указана, будет использована фраза по умолчанию.

charset — кодировка символов, в которой будет закодирован ответ. Если не задана, она извлекается из content_type, а если это не удается, используется значение настройки DEFAULT_CHARSET.

HttpResponse.__setitem__(header, value)

Устанавливает указанное имя заголовка в указанное значение. Оба header и value должны быть строками.

HttpResponse.__delitem__(header)

Удаляет заголовок с заданным именем. Безмолвно завершается, если заголовок не существует. Регистронезависимый поиск.

HttpResponse.__getitem__(header)

Возвращает значение для заданного имени заголовка. Регистронезависимый поиск.

HttpResponse.has_header(header)

Возвращает True или False на основе регистронезависимой проверки наличия заголовка с заданным именем.

HttpResponse.setdefault(header, value)

Устанавливает заголовок, если он ещё не установлен.

HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False, samesite=None)

Устанавливает cookie. Параметры такие же, как в объекте cookie Morsel стандартной библиотеки Python.

• max_age должен быть количеством секунд, или None (по умолчанию), если cookie должна действовать только в течение сессии браузера клиента. Если expires не указано, оно будет рассчитано.
• expires должен быть строкой в формате "Wdy, DD-Mon-YY HH:MM:SS GMT" или объектом datetime.datetime в формате UTC. Если expires является объектом datetime, время max_age будет рассчитано.
• Используйте domain для установки cookie для разных доменов. Например, domain="example.com" установит cookie, который будет доступен для доменов www.example.com, blog.example.com и т.д. В противном случае cookie будет доступна только для домена, который его установил.

• Используйте httponly=True, чтобы предотвратить доступ к cookie со стороны JavaScript на стороне клиента.

  HTTPOnly — это флаг, включенный в заголовок HTTP-ответа Set-Cookie. Он не является частью стандарта RFC 2109 для cookie, и не поддерживается всеми браузерами. Однако, если он поддерживается, он может быть полезным способом снизить риск доступа защищенных данных cookie со стороны скрипта на стороне клиента.

• Используйте samesite='Strict' или samesite='Lax' чтобы не отправлять данную cookie при выполнении запроса с другого домена. SameSite не поддерживается всеми браузерами, поэтому это не замена защиты CSRF в Django, а скорее мера защиты на нескольких уровнях.

Изменено в Django 2.1:

Добавлен параметр samesite.

Предупреждение

И RFC 2109, и RFC 6265 указывают, что агенты пользователя должны поддерживать cookie размером не менее 4096 байт. Для многих браузеров это также максимальный размер. Django не будет генерировать исключение, если будет попытка сохранить cookie размером более 4096 байт, но многие браузеры не установят cookie должным образом.

HttpResponse.set_signed_cookie(key, value, salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False, samesite=None)

Как и set_cookie(), но подписывает cookie с помощью криптографического шифрования перед её установкой. Используется совместно с HttpRequest.get_signed_cookie(). Можно использовать необязательный параметр salt для увеличения защиты ключа, но необходимо помнить, чтобы передать его и соответствующему вызову HttpRequest.get_signed_cookie().

HttpResponse.delete_cookie(key, path='/', domain=None)

Удаляет cookie с заданным ключом. Без ошибок, если ключ не существует.

Из-за особенностей работы cookie, path и domain должны быть такими же, как и при использовании в set_cookie() — иначе cookie может не удалиться.

HttpResponse.write(content) [source]

Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse.flush()

Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse.tell() [source]

Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse.getvalue() [source]

Возвращает значение HttpResponse.content. Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse.readable()

Всегда False. Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse.seekable()

Всегда False. Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse.writable() [source]

Всегда True. Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse.writelines(lines) [source]

Записывает список строк в ответ. Разделители строк не добавляются. Этот метод делает экземпляр HttpResponse объектом типа «поток».

HttpResponse подклассы

Django включает несколько HttpResponse подклассов, которые обрабатывают различные типы HTTP-ответов. Как и HttpResponse, эти подклассы находятся в django.http.

class HttpResponseRedirect [source]

Первый аргумент конструктора обязателен — путь для перенаправления. Это может быть полный URL (например, 'https://www.yahoo.com/search/'), абсолютный путь без домена (например, '/search/') или даже относительный путь (например, 'search/'). В последнем случае браузер клиента сам восстановит полный URL в соответствии с текущим путем. См. HttpResponse для других необязательных аргументов конструктора. Обратите внимание, что это возвращает HTTP-код состояния 302.

url

Это только для чтения атрибут, представляющий URL, на который будет перенаправлен ответ (эквивалентен заголовку ответа Location).

class HttpResponsePermanentRedirect [source]

Как и HttpResponseRedirect, но возвращает постоянное перенаправление (HTTP-код состояния 301) вместо временного перенаправления (код состояния 302).

class HttpResponseNotModified [source]

Конструктор не принимает никаких аргументов, и к этому ответу не должно быть добавлено никакого содержимого. Используйте этот ответ, чтобы указать, что страница не изменялась с момента последнего запроса пользователя (код состояния 304).

class HttpResponseBadRequest [source]

Ведёт себя как HttpResponse, но использует код состояния 400.

class HttpResponseNotFound [source]

Ведёт себя как HttpResponse, но использует код состояния 404.

class HttpResponseForbidden [source]

Ведёт себя как HttpResponse, но использует код состояния 403.

class HttpResponseNotAllowed [source]

Подобно HttpResponse, но использует код состояния 405. Первый аргумент конструктора обязателен: список разрешенных методов (например, ['GET', 'POST']).

class HttpResponseGone [source]

Ведёт себя так же, как HttpResponse, но использует код состояния 410.

class HttpResponseServerError [source]

Ведёт себя так же, как HttpResponse, но использует код состояния 500.

JsonResponse объекты

class JsonResponse(data, encoder=DjangoJSONEncoder, safe=True, json_dumps_params=None, **kwargs) [source]

Подкласс HttpResponse, который помогает создавать ответ в формате JSON. Он наследует большинство свойств своего суперкласса, но с некоторыми отличиями:

По умолчанию заголовок Content-Type устанавливается в application/json.

Первый параметр, data, должен быть экземпляром dict. Если параметр safe установлен в False (см. ниже), он может быть любым сериализуемым в JSON объектом.

Для сериализации данных используется encoder, по умолчанию django.core.serializers.json.DjangoJSONEncoder. Подробную информацию о сериализаторе см. в разделе Сериализация в формате JSON.

Параметр safe, по умолчанию, True. Если он установлен в False, для сериализации можно передать любой объект (в противном случае допускаются только экземпляры dict). Если safe равен True, и в качестве первого аргумента передан не объект типа dict, будет возбуждено исключение TypeError.

Параметр json_dumps_params — словарь с ключевыми аргументами, которые нужно передать в вызов json.dumps(), используемый для генерации ответа.

Использование

Типичное использование может выглядеть следующим образом:

>>> from django.http import JsonResponse
>>> response = JsonResponse({'foo': 'bar'})
>>> response.content
b'{"foo": "bar"}'

Сериализация объектов, не являющихся словарями

Для сериализации объектов, отличных от dict, необходимо установить параметр safe в False.

>>> response = JsonResponse([1, 2, 3], safe=False)

Без передачи safe=False, будет возбуждено исключение TypeError.

Изменение кодировщика JSON по умолчанию

Если вам нужно использовать другой кодировщик JSON, вы можете передать параметр encoder в метод конструктора:

>>> response = JsonResponse(data, encoder=MyJSONEncoder)

StreamingHttpResponse объекты

class StreamingHttpResponse [source]

Класс StreamingHttpResponse используется для потоковой передачи ответа от Django в браузер. Это может быть полезно, если генерация ответа занимает слишком много времени или использует слишком много памяти. Например, это полезно для генерации больших CSV-файлов.

Класс StreamingHttpResponse не является подклассом HttpResponse, так как имеет немного другой API. Однако он почти идентичен с следующими важными отличиями:

• Ему должен быть передан итератор, возвращающий строки в качестве содержимого.
• К его содержимому нельзя обратиться, кроме как итерируя сам объект ответа. Это должно произойти только при возвращении ответа клиенту.
• У него нет атрибута content. Вместо этого у него есть атрибут streaming_content.
• Вы не можете использовать объект-подобный файл tell() или методы write(). В противном случае возникнет исключение.

Класс StreamingHttpResponse следует использовать только в ситуациях, когда абсолютно необходимо, чтобы все содержимое не было обработано перед передачей данных клиенту. Так как к содержимому нельзя обратиться, многие middleware не могут работать нормально. Например, заголовки ETag и Content-Length не могут быть сгенерированы для потоковых ответов.

Атрибуты

StreamingHttpResponse.streaming_content

Итератор строк, представляющих содержимое.

StreamingHttpResponse.status_code

Код состояния HTTP для ответа.

Если reason_phrase не задан явно, изменение значения status_code вне конструктора также изменит значение reason_phrase.

StreamingHttpResponse.reason_phrase

Фраза причины HTTP для ответа. Используются фразы причин по умолчанию из стандарта HTTP.

Если явно не задано, reason_phrase определяется значением status_code.

StreamingHttpResponse.streaming

Это всегда True.

FileResponse объекты

class FileResponse(open_file, as_attachment=False, filename='', **kwargs) [source]

FileResponse — подкласс StreamingHttpResponse, оптимизированный для бинарных файлов. Он использует wsgi.file_wrapper, если он предоставлен сервером WSGI, в противном случае файл передается небольшими частями.

Если as_attachment=True, устанавливается заголовок Content-Disposition, который просит браузер предложить пользователю скачать файл.

Если у open_file нет имени или имя open_file не подходит, укажите имя файла с помощью параметра filename.

Заголовки Content-Length, Content-Type, и Content-Disposition автоматически устанавливаются, если они могут быть определены из содержимого open_file.

Добавлено в Django 2.1:

Были добавлены ключевые аргументы as_attachment и filename. Кроме того, FileResponse устанавливает заголовки Content, если может их определить.

FileResponse принимает любой объект-подобный файлу с бинарным содержимым, например, файл, открытый в бинарном режиме, как показано ниже:

>>> from django.http import FileResponse
>>> response = FileResponse(open('myfile.png', 'rb'))

Файл будет автоматически закрыт, поэтому не открывайте его с помощью менеджера контекста.

Методы

FileResponse.set_headers(open_file) [source]

Новое в Django 2.1.

Этот метод автоматически вызывается во время инициализации ответа и устанавливает различные заголовки (Content-Length, Content-Type, и Content-Disposition) в зависимости от open_file.