Spec-Zone.ru › Django 1.11

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

Быстрый обзор

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 может упростить перенося код между тестовыми и рабочими серверами.

Например, если префикс скрипта для вашего приложения установлен как "/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

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

HttpRequest.POST

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

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

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

HttpRequest.COOKIES

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

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.

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

Некоторые средства обработки, включенные в приложения Django contrib, устанавливают атрибуты в запросе. Если вы не видите атрибут в запросе, убедитесь, что соответствующий класс средства обработки указан в 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.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 может быть использован для дополнительной защиты от атак методом перебора возможных ключей.

Пример:

>>> 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-данного с помощью итеративного парсера без создания всего 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 в unicode. Если encoding не задано, используется значение по умолчанию DEFAULT_CHARSET.

classmethod QueryDict.fromkeys(iterable, value='', mutable=False, encoding=None) [source]
Добавлен в Django 1.11.

Создаёт новый 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')
>>> q.items()
[('a', '3')]
QueryDict.iteritems()

Аналогично dict.iteritems(), но использует логику последнего значения, аналогичную __getitem__().

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

QueryDict.iterlists()

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

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

QueryDict.values()

Как dict.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(). Эта копия будет изменяемой, даже если оригинал не был.

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 вместо него.

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

Объекты с методом close() закрывались, когда WSGI-сервер вызывал close() на ответе.

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

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

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

Строка, обозначающая кодировку символов, в которой будет закодирован ответ. Если не задано во время создания HttpResponse , оно будет извлечено из content_type и, если это не удалось, будет использовано значение настройки 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)

Устанавливает 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 для предотвращения доступа к cookie со стороны JavaScript на стороне клиента.

    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=False)

Как 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()
Добавлено в 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.

Примечание

Если пользовательский подкласс HttpResponse реализует метод render, Django будет обрабатывать его как эмуляцию SimpleTemplateResponse, и метод render сам должен возвращать допустимый объект ответа.

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.

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

До пятой редакции ECMAScript было возможно заразить конструктор JavaScript Array. По этой причине Django по умолчанию не допускает передачи объектов, отличных от словарей, в конструктор JsonResponse. Однако большинство современных браузеров используют ECMAScript 5, что устраняет этот вектор атаки. Поэтому можно отключить эту предосторожность безопасности.

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

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

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

StreamingHttpResponse объекты

class StreamingHttpResponse [source]

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

Соображения по производительности

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

В целом, следует выполнять ресурсоемкие задачи за пределами цикла запроса-ответа, а не прибегать к потоковому ответу.

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

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

Класс StreamingHttpResponse следует использовать только в ситуациях, когда абсолютно необходимо, чтобы всё содержимое не обрабатывалось до передачи данных клиенту. Так как к содержимому невозможно получить доступ, многие средние слои не могут работать нормально. Например, заголовки 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 [source]

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

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

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

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.11/ref/request-response/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API