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

Краткое описание

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

Устаревшее с версии 1.7: Используйте более явные GET и POST вместо него.

Для удобства, объект, подобный словарю, который ищет сначала POST, а затем GET. Вдохновлено $_REQUEST PHP.

Например, если GET = {"name": "john"} и POST = {"age": '34'}, то REQUEST["name"] будет "john", и REQUEST["age"] будет "34".

Сильно рекомендуется использовать GET и POST вместо REQUEST, потому что первые более явные.

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 — строка 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.urlconf

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

HttpRequest.resolver_match

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

HttpRequest.current_app

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

Атрибуты, установленные middleware

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

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() терпит неудачу, когда хост находится за несколькими прокси. Одним из решений является использование middleware для переписывания заголовков прокси, как в следующем примере:

class MultipleProxyMiddleware(object):
    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()

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

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 строится с использованием переменных сервера, доступных в этом запросе.

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

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 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 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 будут неизменяемыми при обращении в обычном цикле запроса/ответа. Для получения изменяемого варианта необходимо использовать .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.

В предыдущих версиях query_string был обязательным позиционным аргументом.

QueryDict.__getitem__(key)

Возвращает значение для данного ключа. Если ключ имеет более одного значения, __getitem__() возвращает последнее значение. Вызывает исключение django.utils.datastructures.MultiValueDictKeyError если ключ не существует. (Это подкласс стандартного KeyError 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__().

QueryDict.iterlists()

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

QueryDict.values()

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

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

QueryDict.itervalues()

Как QueryDict.values(), за исключением итератора.

Кроме того, у 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 немедленно обработает итератор, сохранит его содержимое как строку и удалит его.

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

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

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

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

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

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

Поля заголовков 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 для ответа.

HttpResponse.reason_phrase

Текст фразы кода состояния HTTP для ответа.

HttpResponse.streaming

Это всегда False.

Этот атрибут существует для того, чтобы middleware мог обрабатывать потоковые ответы иначе, чем обычные.

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.

Параметр 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(), но криптографически подписывает 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.writable() [source]

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

HttpResponse.writelines(lines) [source]

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

Подклассы HttpResponse

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

class HttpResponseRedirect [source]

Первый аргумент конструктора обязателен — путь для перенаправления. Это может быть полный URL (например, 'http://www.yahoo.com/search/') или абсолютный путь без домена (например, '/search/'). См. 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, **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.

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

Типичное использование может выглядеть так:

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

Атрибуты

StreamingHttpResponse.streaming_content

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

StreamingHttpResponse.status_code

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

StreamingHttpResponse.reason_phrase

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

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