Spec-Zone.ru › Django 5.2

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

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

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

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

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

HttpRequest объекты

class HttpRequest [source]

Атрибуты

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

HttpRequest.scheme [source]

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

HttpRequest.body [source]

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

Также можно читать из HttpRequest с помощью интерфейса типа файла с помощью HttpRequest.read() или HttpRequest.readline(). Доступ к атрибуту body после чтения запроса с помощью любого из этих методов потока ввода/вывода приведет к RawPostDataException.

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 [source]

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

HttpRequest.content_type

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

HttpRequest.content_params

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

HttpRequest.GET

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

HttpRequest.POST

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

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

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

HttpRequest.COOKIES

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

HttpRequest.FILES

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

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

FILES будет содержать данные только в том случае, если метод запроса был POST, и форма, которая отправила запрос, имела <form>. В противном случае, 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.headers – более простой способ доступа ко всем HTTP-заголовкам, а также CONTENT_LENGTH и CONTENT_TYPE.

HttpRequest.headers [source]

Объект, подобный словарю, предоставляющий доступ ко всем HTTP-заголовкам запроса (плюс Content-Length и Content-Type) с регистронезависимым поиском.

Имя каждого заголовка стилизуется с использованием заглавной буквы (например, User-Agent) при отображении. Вы можете получить доступ к заголовкам регистронезависимо:

>>> request.headers
{'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6', ...}

>>> "User-Agent" in request.headers
True
>>> "user-agent" in request.headers
True

>>> request.headers["User-Agent"]
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
>>> request.headers["user-agent"]
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)

>>> request.headers.get("User-Agent")
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
>>> request.headers.get("user-agent")
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)

Для использования, например, в шаблонах Django, заголовки также можно искать, используя подчёркивания вместо дефисов:

{{ request.headers.user_agent }}
END_OF_DOCUMENT_MARKER
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, чтобы отменить все изменения, внесённые предыдущим middleware, и вернуться к использованию ROOT_URLCONF.

HttpRequest.exception_reporter_filter

Он будет использоваться вместо DEFAULT_EXCEPTION_REPORTER_FILTER для текущего запроса. Подробности см. в Настройка сообщений об ошибках.

HttpRequest.exception_reporter_class

Он будет использоваться вместо DEFAULT_EXCEPTION_REPORTER для текущего запроса. Подробности см. в Настройка сообщений об ошибках.

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

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

Метод auser() делает то же самое, но может быть использован из асинхронных контекстов.

Методы

HttpRequest.auser()

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

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"

Вызывает django.core.exceptions.DisallowedHost, если хост не находится в ALLOWED_HOSTS или имя домена недействительно в соответствии с RFC 1034/1035.

Примечание

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

class MultipleProxyMiddleware:
    FORWARDED_FOR_FIELDS = [
        "HTTP_X_FORWARDED_FOR",
        "HTTP_X_FORWARDED_HOST",
        "HTTP_X_FORWARDED_SERVER",
    ]

    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(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()
        return self.get_response(request)

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

HttpRequest.get_port() [source]

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

HttpRequest.get_full_path() [source]

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

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

HttpRequest.get_full_path_info() [source]

Аналогично get_full_path(), но использует path_info вместо path.

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

HttpRequest.build_absolute_uri(location=None) [source]

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

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

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

Примечание

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

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

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

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

Например:

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

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

HttpRequest.is_secure() [source]

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

HttpRequest.get_preferred_type(media_types) [source]
Добавлен в Django 5.2.

Возвращает предпочтительный тип MIME из media_types, основанный на заголовке Accept, или None, если клиент не принимает ни одного из предоставленных типов.

Предполагая, что клиент отправляет заголовок Accept со значением text/html,application/json;q=0.8:

>>> request.get_preferred_type(["text/html", "application/json"])
"text/html"
>>> request.get_preferred_type(["application/json", "text/plain"])
"application/json"
>>> request.get_preferred_type(["application/xml", "text/plain"])
None

Большинство браузеров отправляют Accept: */* по умолчанию, что означает, что у них нет предпочтения, в этом случае будет возвращён первый элемент в media_types.

Установка явного заголовка Accept в запросах API может быть полезной для возвращения другого типа содержимого только для этих потребителей. См. Пример переговорного процесса содержимого для примера возвращения различного содержимого на основе заголовка Accept.

Примечание

Если ответ различается в зависимости от содержимого заголовка Accept и вы используете какую-либо форму кэширования, например Django's cache middleware, вы должны декорировать представление с помощью vary_on_headers('Accept'), чтобы ответы кэшировались должным образом.

HttpRequest.accepts(mime_type) [source]

Возвращает True, если заголовок Accept запроса соответствует аргументу mime_type:

>>> request.accepts("text/html")
True

Большинство браузеров отправляют Accept: */* по умолчанию, поэтому это вернёт True для всех типов содержимого.

См. Пример переговорного процесса содержимого для примера использования accepts() для возвращения различного содержимого на основе заголовка Accept.

HttpRequest.read(size=None) [source]
HttpRequest.readline() [source]
HttpRequest.readlines() [source]
HttpRequest.__iter__() [source]

Методы, реализующие интерфейс файла для чтения из объекта 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 в str. Если encoding не задан, он по умолчанию равен DEFAULT_CHARSET.

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

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

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

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

>>> q = QueryDict("a=1&a=2&a=3", mutable=True)
>>> q.__getitem__("a")
'3'
>>> q.__setitem__("b", [])
>>> q.__getitem__("b")
[]
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)

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

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

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

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

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

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

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

QueryDict.copy() [source]

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

QueryDict.getlist(key, default=None)

Возвращает список данных с запрошенным ключом. Возвращает пустой список, если ключ не существует и 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 в виде строки, байтовой строки или memoryview:

>>> 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 = HttpResponse(b"Bytestrings are also accepted.")
>>> response = HttpResponse(memoryview(b"Memoryview as well."))

Но если вы хотите добавлять содержимое по частям, вы можете использовать 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.

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

Для установки или удаления поля заголовка в ответе используйте HttpResponse.headers:

>>> response = HttpResponse()
>>> response.headers["Age"] = 120
>>> del response.headers["Age"]

Вы также можете изменять заголовки, рассматривая ответ как словарь:

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

Это делегирует вызов методу HttpResponse.headers и является исходным интерфейсом, предлагаемым HttpResponse.

Используя этот интерфейс, в отличие от словаря, del не генерирует исключение KeyError, если поля заголовка не существует.

Вы также можете устанавливать заголовки при создании:

>>> response = HttpResponse(headers={"Age": 120})

Для установки полей заголовков 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,
...     headers={
...         "Content-Type": "application/vnd.ms-excel",
...         "Content-Disposition": 'attachment; filename="foo.xls"',
...     },
... )

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

Атрибуты

HttpResponse.content [source]

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

HttpResponse.text [source]
Добавлен в Django 5.2.

Строковое представление HttpResponse.content, декодированное с использованием кодировки ответа HttpResponse.charset (по умолчанию UTF-8, если пусто).

HttpResponse.cookies

Объект http.cookies.SimpleCookie, содержащий куки, включённые в ответ.

HttpResponse.headers

Нечувствительный к регистру, похожий на словарь объект, предоставляющий доступ ко всем HTTP-заголовкам ответа, кроме заголовка Set-Cookie. См. Установка полей заголовков и HttpResponse.cookies.

HttpResponse.charset

Строка, обозначающая кодировку, в которой будет закодирован ответ. Если не задано при создании, оно извлекается из 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=b'', content_type=None, status=200, reason=None, charset=None, headers=None) [source]

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

content чаще всего является итератором, байтовой строкой, memoryview или строкой. Другие типы будут преобразованы в байтовую строку путём кодирования их строкового представления. Итераторы должны возвращать строки или байтовые строки, которые будут объединены для формирования содержимого ответа.

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

status — это код состояния HTTP для ответа. Вы можете использовать алиасы Python http.HTTPStatus, такие как HTTPStatus.NO_CONTENT.

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

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

headers — это dict HTTP-заголовков для ответа.

HttpResponse.__setitem__(header, value)

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

HttpResponse.__delitem__(header)

Удаляет заголовок с заданным именем. Если заголовок не существует, не выдает ошибок. Нечувствительно к регистру.

HttpResponse.__getitem__(header)

Возвращает значение для заданного имени заголовка. Нечувствительно к регистру.

HttpResponse.get(header, alternate=None)

Возвращает значение для заданного заголовка или alternate, если заголовок не существует.

HttpResponse.has_header(header)

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

HttpResponse.items()

Ведёт себя как dict.items() для HTTP-заголовков ответа.

HttpResponse.setdefault(header, value)

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

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

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

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

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

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

    Используйте samesite='None' (строка), чтобы явно указать, что этот куки отправляется с любыми запросами SameSite и Cross-Site.

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

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

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

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

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

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

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

HttpResponse.close()

Этот метод вызывается в конце запроса непосредственно сервером WSGI.

HttpResponse.write(content) [source]

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

HttpResponse.flush()

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

HttpResponse.tell() [source]

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

HttpResponse.getvalue() [source]

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

HttpResponse.readable()

Всегда False. Этот метод делает экземпляр HttpResponse объектом, похожим на поток.

HttpResponse.seekable()

Всегда False. Этот метод делает экземпляр HttpResponse объектом, похожим на поток.

END_OF_DOCUMENT_MARKER
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-адрес в соответствии с текущим путем.

Конструктор принимает необязательный аргумент preserve_request, который по умолчанию равен False, генерируя ответ со статусом 302. Если preserve_request равно True, код статуса будет 307.

См. HttpResponse для других необязательных аргументов конструктора.

url

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

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

Был добавлен аргумент preserve_request.

class HttpResponsePermanentRedirect [source]

Аналогично HttpResponseRedirect, но возвращает постоянное перенаправление (HTTP-код статуса 301) вместо перенаправления «найдено» (код статуса 302). Если preserve_request=True, код статуса ответа будет 308.

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

Был добавлен аргумент preserve_request.

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 должен сам возвращать допустимый объект ответа.

Пользовательские классы ответов

Если вам понадобится класс ответа, которого нет в Django, вы можете создать его с помощью http.HTTPStatus. Например:

from http import HTTPStatus
from django.http import HttpResponse


class HttpResponseNoContent(HttpResponse):
    status_code = HTTPStatus.NO_CONTENT

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.

Обратите внимание, что API, основанный на объектах dict, более расширяем, гибкий и упрощает поддержание обратной совместимости. Поэтому следует избегать использования объектов, не являющихся словарями, в JSON-кодированных ответах.

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

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

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

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

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

StreamingHttpResponse объекты

class StreamingHttpResponse [source]

Класс StreamingHttpResponse используется для потоковой передачи ответа из Django в браузер.

Расширенное использование

StreamingHttpResponse является достаточно сложным в использовании, поскольку важно понимать, будете ли вы обслуживать своё приложение синхронно по WSGI или асинхронно по ASGI, и соответствующим образом настраивать его.

Пожалуйста, внимательно прочтите эти замечания.

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

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

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

Однако, при обслуживании по ASGI, StreamingHttpResponse не должен препятствовать обработке других запросов, ожидая I/O. Это открывает возможность для долгоживущих запросов для потокового содержимого и реализации таких шаблонов, как long-polling и server-sent events.

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

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

  • Ему должен быть передан итератор, который возвращает байтовые строки, memoryview, или строки в качестве содержимого. При обслуживании в WSGI это должен быть синхронный итератор. При обслуживании в ASGI, это должен быть асинхронный итератор.
  • Вы не можете получить доступ к его содержимому, кроме как итерируя сам объект ответа. Это должно происходить только тогда, когда ответ возвращается клиенту: вы не должны итерировать ответ самостоятельно.

    В WSGI ответ будет итерироваться синхронно. В ASGI ответ будет итерироваться асинхронно. (Вот почему тип итератора должен соответствовать используемому протоколу.)

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

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

Базовый класс HttpResponseBase используется как в HttpResponse, так и в StreamingHttpResponse.

Атрибуты

StreamingHttpResponse.streaming_content [source]

Итератор содержимого ответа, закодированного в байты в соответствии с HttpResponse.charset.

StreamingHttpResponse.status_code

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

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

StreamingHttpResponse.reason_phrase

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

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

StreamingHttpResponse.streaming

Это всегда True.

StreamingHttpResponse.is_async

Булево значение, указывающее, является ли StreamingHttpResponse.streaming_content асинхронным итератором или нет.

Это полезно для middleware, которому необходимо обернуть StreamingHttpResponse.streaming_content.

Обработка разъединений

Если клиент отсоединяется во время потокового ответа, Django отменит сопрограмму, обрабатывающую ответ. Если вы хотите очистить ресурсы вручную, вы можете сделать это, поймав asyncio.CancelledError:

async def streaming_response():
    try:
        # Do some work here
        async for chunk in my_streaming_iterator():
            yield chunk
    except asyncio.CancelledError:
        # Handle disconnect
        ...
        raise


async def my_streaming_view(request):
    return StreamingHttpResponse(streaming_response())

Этот пример показывает только как обработать отключение клиента во время потоковой передачи ответа. Если вы выполняете длительные операции в вашем представлении перед возвращением объекта StreamingHttpResponse, то вы также можете обрабатывать отключения в самом представлении.

FileResponse объекты

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

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

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

Если у open_file нет имени или имя open_file не подходит, укажите пользовательское имя файла, используя параметр filename. Обратите внимание, что если вы передаёте файлоподобный объект, как io.BytesIO, вы должны seek() его перед передачей в FileResponse.

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

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

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

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

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

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

API файлов Python синхронный. Это означает, что файл должен быть полностью обработан для обслуживания в ASGI.

Для асинхронного потока файла вам необходимо использовать сторонний пакет, предоставляющий асинхронный API для файлов, например, aiofiles.

Методы

FileResponse.set_headers(open_file) [source]

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

HttpResponseBase класс

class HttpResponseBase [source]

Класс HttpResponseBase является общим для всех ответов Django. Его не следует использовать для прямого создания ответов, но он может быть полезен для проверки типов.

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

Spec-Zone.ru

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