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

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

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

Добавлено в Django 1.10.

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

HttpRequest.content_params

Добавлено в Django 1.10.

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

HttpRequest.GET

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

HttpRequest.POST

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

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

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

HttpRequest.COOKIES

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

HttpRequest.FILES

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

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

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

HttpRequest.META

Стандартный Python-словарь, содержащий все доступные 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.

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

Установка urlconf=None вызывала ImproperlyConfigured в более старых версиях.

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

Некоторые средства обработки, включённые в приложения 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]

Добавлена в Django 1.9.

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

HttpRequest.get_full_path() [source]

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

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

HttpRequest.build_absolute_uri(location) [source]

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

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

Пример: "https://example.com/music/bands/the_beatles/?print=true"

Примечание

Смешивание 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('non-existing-cookie')
...
KeyError: 'non-existing-cookie'
>>> request.get_signed_cookie('non-existing-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's cache middleware, вы должны декорировать представление vary_on_headers('X-Requested-With'), чтобы ответы были правильно кэшированы.

HttpRequest.read(size=None) [source]

HttpRequest.readline() [source]

HttpRequest.readlines() [source]

HttpRequest.xreadlines() [source]

HttpRequest.__iter__()

Методы, реализующие интерфейс файлоподобного объекта для чтения из экземпляра HttpRequest. Это позволяет потреблять входящий запрос потоковым способом. Типичный сценарий использования — обработка большого XML-нагрузки с итерационным парсером без построения целого 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 будут неизменяемыми при доступе в обычном цикле запроса/ответа. Чтобы получить изменяемую копию, необходимо использовать .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 в unicode. Если кодировка не задана, она по умолчанию установлена как DEFAULT_CHARSET.

QueryDict.__getitem__(key)

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

QueryDict.__setitem__(key, value) [source]

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

QueryDict.__contains__(key)

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

QueryDict.get(key, default=None)

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

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

Точно так же, как и стандартный метод словаря setdefault(), за исключением того, что он использует __setitem__() внутри.

QueryDict.update(other_dict)

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

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

QueryDict.items()

Точно так же, как и стандартный метод словаря items(), за исключением того, что он использует ту же логику, что и __getitem__(), для выбора последнего значения. Например:

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

QueryDict.iteritems()

Точно так же, как и стандартный метод словаря iteritems(). Как и QueryDict.items(), он использует ту же логику для выбора последнего значения, что и QueryDict.__getitem__().

Доступен только в Python 2.

QueryDict.iterlists()

Подобно QueryDict.iteritems(), но возвращает все значения в виде списка для каждого элемента словаря.

Доступен только в Python 2.

QueryDict.values()

Точно так же, как и стандартный метод словаря values(), за исключением того, что он использует ту же логику для выбора последнего значения, что и __getitem__(). Например:

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

QueryDict.itervalues()

Подобно QueryDict.values(), но в виде итератора.

Доступен только в Python 2.

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

QueryDict.copy() [source]

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

QueryDict.getlist(key, default=None)

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

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'

В urlencode можно передавать символы, не требующие кодирования. Например:

>>> 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

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

HttpResponse.charset

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

HttpResponse.status_code

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

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

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

HttpResponse.reason_phrase

Фраза причины HTTP ответа.

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

reason_phrase больше не по умолчанию в верхнем регистре. Теперь он использует значения по умолчанию из стандарта 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)

Устанавливает 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=".lawrence.com" установит cookie, доступный для доменов www.lawrence.com, blogs.lawrence.com и calendars.lawrence.com. В противном случае cookie будет доступен только для домена, который его установил.

• Используйте httponly=True для предотвращения доступа клиентского JavaScript к cookie.

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

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

И 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=True)

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

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

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

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

HttpResponse.write(content) [source]

Этот метод делает объект HttpResponse похожим на объект файла.

HttpResponse.flush()

Этот метод делает объект HttpResponse похожим на объект файла.

HttpResponse.tell() [source]

Этот метод делает объект HttpResponse похожим на объект файла.

HttpResponse.getvalue() [source]

Возвращает значение HttpResponse.content. Этот метод делает объект HttpResponse похожим на потоковый объект.

HttpResponse.readable()

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

Всегда False. Этот метод делает объект HttpResponse похожим на потоковый объект.

HttpResponse.seekable()

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

Всегда 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() для генерации ответа.

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

Добавлен аргумент json_dumps_params.

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

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

>>> 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.
• Вы не можете использовать объекты типа file tell() или методы write(). В противном случае возникнет исключение.

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

Атрибуты

StreamingHttpResponse.streaming_content

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

StreamingHttpResponse.status_code

Код HTTP статуса ответа.

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

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

StreamingHttpResponse.reason_phrase

Фраза причины HTTP ответа.

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

reason_phrase больше не по умолчанию записывается большими буквами. Теперь он использует значения фраз причины по умолчанию из стандарта HTTP.

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

StreamingHttpResponse.streaming

Это всегда True.

FileResponse объекты

class FileResponse [source]

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

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

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