Request django что это

Путь от request до response в Джанго

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

При настройке нового проекта Django первое, что вы сделаете, это подключите ваши URLconfs и создадите какие-то представления. Но что на самом деле происходит «под капотом»? Как Django направляет трафик к представлению и какую роль играют промежуточное ПО (middleware) в этом цикле?

WSGI

Как мы знаем, веб-сервер — это программа, которая использует HTTP (протокол передачи гипертекста) для предоставления пользователям данных, формирующих веб-страницы, в ответ на их запросы, которые пересылаются HTTP-клиентами их компьютеров.

WSGI — это инструмент, созданный для решения основной проблемы: подключения веб-сервера к веб-среде. WSGI имеет две стороны: «серверная» и «прикладная». Для обработки ответа WSGI сервер выполняет приложение и предоставляет функцию обратного вызова на стороне приложения. Приложение обрабатывает запрос и возвращает ответ на сервер, используя предоставленный обратный вызов. По сути, обработчик WSGI действует как привратник между вашим веб-сервером (Apache, NGINX и т.д.) и вашим проектом на Django.

Между сервером и приложением лежат промежуточные программы (middleware). Вы можете думать о промежуточном программном обеспечении как о серии двунаправленных фильтров: они могут изменять (или замыкать) данные, передаваемые назад и вперед между сетью и вашим приложением Django.

Большая картина — поток данных

Когда пользователь делает запрос к вашему приложению, создается экземпляр обработчика WSGI, который:

1. Импортирует ваш файл settings.py и классы исключений Django.
2. Загружает все промежуточные классы, которые он находит в кортеже MIDDLEWARE_CLASSES или MIDDLEWARES (в зависимости от версии Django), расположенном в settings.py
3. Создает четыре списка методов, которые обрабатывают запрос, представление, ответ и исключения.
4. Перебирает методы запроса, выполняя их по порядку
5. Определяет запрошенный URL
6. Проходит через каждый из методов обработки представления
7. Вызывает функцию отображения (обычно рендеринг шаблона)
8. Обрабатывает любые методы исключения
9. Проходит через каждый из методов ответа (изнутри, в обратном порядке из промежуточного ПО запроса)
10. Наконец, создает возвращаемое значение и вызывает функцию обратного вызова на веб-сервере

Слои приложения Джанго

1. Request Middlewares — Запрос промежуточного программного обеспечения
2. URL Router (URL Dispatcher) — Маршрутизация URL
3. Views — Отображения
4. Context Processors — Контекстные процессоры
5. Template Renderers — Рендер шаблонов
6. Response Middlewares — Промежуточное программное обеспечение ответа

Всякий раз, когда поступает запрос, он обрабатывается промежуточным программным обеспечением. Мы можем иметь несколько промежуточных программ. Найти их можно в настройках проекта ( settings.py ). Промежуточное ПО запросов Django происходит по порядку при обработке запроса. Предположим, что если у нас есть запрос промежуточного программного обеспечения в порядке A, B, C, то запрос сначала обрабатывается промежуточным программным обеспечением A, а затем B, а затем C. Django предлагает связку промежуточного программного обеспечения по умолчанию. Мы также можем написать наши собственные или пользовательские промежуточные программы. После обработки запроса промежуточным программным обеспечением он будет отправлен на маршрутизатор URL (диспетчер URL).

URL-маршрутизатор примет запрос от промежуточного программного обеспечения запроса (request middleware) и получит путь URL-адреса из запроса. На основе пути URL-маршрутизатор попытается сопоставить путь запроса с доступными шаблонами URL-адреса. Эти шаблоны URL имеют форму регулярных выражений. После сопоставления пути URL с доступными шаблонами URL запрос будет отправлен в представление, связанное с URL.

Теперь мы находимся в слое бизнес-логики. Представления обрабатывают бизнес-логику, используя запрос и данные запроса (данные, отправленные в GET, POST и т.д.). После обработки в представлении запрос отправляется контекстным процессорам, с помощью обработчиков контекста запроса добавляет контекстные данные, которые помогут средству визуализации шаблонов визуализировать шаблон для генерации HTTP-ответа.

И снова запрос будет отправлен обратно в промежуточное программное обеспечение, но уже ответа ( response ) для его обработки. Промежуточное программное обеспечение ответа обработает запрос и добавит или изменит информацию заголовка /информацию тела перед отправкой обратно клиенту (браузеру). После этого браузер обработает и отобразит его для конечного пользователя.

Промежуточное программное обеспечение — Middleware

Промежуточное программное обеспечение используется в ряде ключевых функций в проекте Django: например мы используем промежуточное ПО CSRF для предотвращения атак подделки межсайтовых запросов. Они используются для обработки данных сеанса. Аутентификация и авторизация осуществляется с использованием промежуточного программного обеспечения. Мы можем написать наши собственные классы промежуточного программного обеспечения для формирования (или замыкания) потока данных через ваше приложение.

process_request

Промежуточное ПО Django должно иметь хотя бы один из следующих методов: process_request , process_response , process_view и process_exception . Это методы, которые будут собраны обработчиком WSGI и затем вызваны в порядке их перечисления. Давайте кратко рассмотрим django.contrib.auth.middleware.AuthenticationMiddleware , одну из промежуточных программ, которые устанавливаются по умолчанию при запуске django-admin.py startproject :

def get_user(request): if not hasattr(request, '_cached_user'): request._cached_user = auth.get_user(request) return request._cached_user class AuthenticationMiddleware(MiddlewareMixin): def process_request(self, request): assert hasattr(request, 'session'), ( "The Django authentication middleware requires session middleware" "to be installed. Edit your MIDDLEWARE%s setting to insert " "'django.contrib.sessions.middleware.SessionMiddleware' before " "'django.contrib.auth.middleware.AuthenticationMiddleware'." ) % ("_CLASSES" if settings.MIDDLEWARE is None else "") request.user = SimpleLazyObject(lambda: get_user(request))

Как вы можете видеть, это промежуточное программное обеспечение работает только на этапе «запроса» потока данных, поступающего в приложение Django и из него. Это промежуточное программное обеспечение сначала проверяет, используется ли промежуточное программное обеспечение сеанса и уже было ли оно вызвано, затем устанавливает пользователя, вызывающего вспомогательную функцию get_user . Поскольку обработчик WSGI выполняет итерацию по списку методов process_request , он создает этот объект request , который в конечном итоге будет передан в представление, и вы сможете ссылаться на request.user . Некоторые из промежуточных программ в settings.py не будут иметь методы process_request . Ничего страшного; те просто пропускаются на этом этапе.

process_requests должен либо вернуть None (как в этом примере), либо альтернативно может вернуть объект HttpResponse . В первом случае обработчик WSGI продолжит обрабатывать методы process_request , а второй «закоротит» процесс и начнет цикл process_response .

Определение URL

Теперь, когда каждый из методов process_request был вызван, у нас теперь есть объект запроса, который будет передан представлению. Прежде чем это произойдет, Django должен разрешить URL и определить, какую функцию просмотра вызывать. Это просто делается путем сопоставления регулярных выражений. Ваш файл settings.py будет иметь ключ ROOT_URLCONF , который указывает на корневой файл urls.py , из которого вы будете включать файлы urls.py для каждого из ваших приложений. URL-маршрутизация довольно подробно описана в руководствах по Django, поэтому здесь нет необходимости углубляться в это.

Представление имеет три требования:

1. Это должно быть вызваемым. Это может быть представление на основе функции или представление на основе класса, которое наследуется от метода as_view() класса View , чтобы сделать его вызываемым в зависимости от типа запроса HTTP (GET, POST и т.д.)
2. Оно должно принимать объект HttpRequest в качестве первого позиционного аргумента. Это результат вызова всех методов process_request и process_view .
3. Оно должно возвращать объект HttpResponse или вызывать исключение. Именно этот объект ответа используется для запуска цикла process_view обработчика WSGI.

process_view

Теперь, когда обработчик WSGI знает, какую функцию представления вызывать, он снова просматривает свой список методов промежуточного программного обеспечения. Метод process_view для любого промежуточного программного обеспечения Django объявлен так:

process_view(request, view_function, view_args, view_kwargs)

Как и в случае с process_request , функция process_view должна возвращать либо None, либо объект HttpResponse (или вызывать исключение), что позволяет обработчику WSGI либо продолжать обработку представлений, либо «закорачивать» и возвращать ответ. Взгляните на исходный код промежуточного программного обеспечения CSRF, чтобы увидеть пример process_view в действии. Если файл cookie CSRF присутствует, метод process_view возвращает None, и выполняется представление. Если нет, запрос отклоняется, и процесс замыкается, что приводит к сообщению об ошибке.

process_exception

Если функция представления вызывает исключение, обработчик перебирает свой список методов process_exception . Эти методы выполняются в обратном порядке, от последнего промежуточного программного обеспечения, указанного в файле settings.py , до первого. Если возникает исключение, процесс будет закорочен, и никакие другие process_exception не будут вызваны. Обычно мы полагаемся на обработчики исключений, предоставляемые Django BaseHandler, но вы, безусловно, можете реализовать свою собственную обработку исключений, когда пишете свой собственный класс промежуточного ПО.

process_response

На этом этапе у нас будет объект HttpResponse , возвращаемый представлением или списком методов process_view , созданных обработчиком WSGI, и пришло время поочередно циклически проходить через промежуточное ПО ответа. Это последний шанс для любого промежуточного программного обеспечения изменить данные, и они выполняются из внутреннего слоя наружу. Взгляните на исходный код промежуточного программного обеспечения кеша, чтобы увидеть пример действия process_response : в зависимости от различных условий в вашем приложении (например, отключено ли кэширование, имеем ли мы дело с потоком и т.д.), Нам понадобится ответ хранится в кеше или нет.

Примечание: Есть одно отличие между Django до 1.10 и более поздними версиями: в старом MIDDLEWARE_CLASSES у каждого промежуточного программного обеспечения всегда будет вызываться метод process_response , даже если более раннее промежуточное программное обеспечение закорачивало процесс. В новом MIDDLEWARES только те промежуточные программы и те, которые выполнялись до этого, будут вызывать свои методы process_response . Обратитесь к документации для получения более подробной информации о различиях между MIDDLEWARES и MIDDLEWARE_CLASSES .

Все сделано!

Наконец, обработчик Django WSGI создает возвращаемое значение из объекта HttpResponse и выполняет функцию обратного вызова для отправки этих данных на веб-сервер и для пользователя.

Итак, два ключевых вывода:

1. Теперь мы знаем, как функция представления сопоставляется с URLconf и что на самом деле вызывается (обработчик WSGI).
2. Существует четыре ключевых момента, которые вы можете подключить к циклу запрос/ответ через свое собственное промежуточное ПО: process_request , process_response , process_view и process_exception .

Представления и маршрутизация

Центральным моментом любого веб-приложения является обработка запроса, который отправляет пользователь. В Django за обработку запроса отвечают представления или views . По сути представления представляют функции обработки, которые принимают данные запроса в виде объекта HttpRequest из пакета django.http и генерируют некоторый результат, который затем отправляется пользователю.

По умолчанию представления размещаются в приложении в файле views.py .

Например, возьмем стандартный проект, в который добавлено приложение (например, проект созданный в прошлой главе).

При создании нового проекта файл views.py имеет следующее содержимое:

from django.shortcuts import render # Create your views here.

Данный код пока никак не обрабатывает запросы, он только импортирует функцию render() , которая может использоваться для обработки.

Генерировать результат можно различными способами. Один из них представляет использование класса HttpResponse из пакета django.http, который позволяет отправить текстовое содержимое.

Так, изменим файл views.py следующим образом:

from django.http import HttpResponse def index(request): return HttpResponse("Главная") def about(request): return HttpResponse("О сайте") def contact(request): return HttpResponse("Контакты")

В данном случае определены три функции, которые будут обрабатывать запросы. Каждая функция принимает в качестве параметра request объект HttpRequest , который хранит информацию о запросе. Однако в данном случае она нам не нужны, поэтому параметр никак не используется. Для генерации ответа в конструктор объекта HttpResponse передается некоторая строка. Это может быть в том числе и код html в виде строки.

Чтобы эти функции сопоставлялись с запросами, надо определить для них маршруты в проекте в файле urls.py . В частности, изменим этот файл следующим образом:

from django.urls import path from hello import views urlpatterns = [ path('', views.index), path('about', views.about), path('contact', views.contact), ]

Переменная urlpatterns определяет набор сопоставлений функций обработки с определенными строками запроса. Например, запрос к корню веб-сайта будет обрабатываться функцией index, запрос по адресу «about» будет обрабатываться функцией about, а запрос «contact» — функцией contact.

Запустим проект и обратимся по некоторым из этих адресов.

При этом мы можем отправлять не простой текст, а, например, код html, который затем интерпретируется браузеромю. Так, изменим файл views.py следующим образом:

from django.http import HttpResponse def index(request): return HttpResponse("
Главная
") def about(request): return HttpResponse("
О сайте
") def contact(request): return HttpResponse("
Контакты
")

Соответственно теперь браузер получит код html:

Request django что это

Функции-представления в качестве обязательного параметра получают объект HttpRequest , который хранит информацию о запросе. HttpRequest определяет ряд атрибутов, которые хранят информацию о запросе. Выделим следующие из них:

• scheme : схема запроса (http или https)
• body : представляет тело запроса в виде строки байтов
• path : представляет путь запроса
• method : метод запроса (GET, POST, PUT и т.д.)
• encoding : кодировка
• content_type : тип содержимого запроса (значение заголовка CONTENT_TYPE)
• GET : объект в виде словаря, который содержит параметры запроса GET
• POST : объект в виде словаря, который содержит параметры запроса POST
• COOKIES : отправленные клиентом куки
• FILES : отправленные клиентом файлы
• META : хранит все доступные заголовки http в виде словаря. Набор заголовков зависит от клиента и сервера, некоторые из них:
  • CONTENT_LENGTH : длина содержимого.
  • CONTENT_TYPE : MIME-тип запроса.
  • HTTP_ACCEPT : типы ответа, которые принимает клиент.
  • HTTP_ACCEPT_ENCODING : кодировка, в которой клиент принимает ответ.
  • HTTP_ACCEPT_LANGUAGE : язык ответа, который принимает клиент.
  • HTTP_HOST : хост сервера.
  • HTTP_REFERER : страница, с которой клиент отправил запрос (при ее наличии).
  • HTTP_USER_AGENT : юзер-агент или информация о браузере клиента.
  • QUERY_STRING : строка запроса.
  • REMOTE_ADDR : IP-адрес клиента.
  • REMOTE_HOST : имя хоста клиента.
  • REMOTE_USER : аутентификационные данные клиента (при наличии)
  • REQUEST_METHOD : тип запроса (GET, POST).
  • SERVER_NAME : имя хоста сервера.
  • SERVER_PORT : порт сервера.

  Также HttpRequest определяет ряд методов. Отметим следующие из них:

  • get_full_path() : возвращает полный путь запроса, включая строку запроса
  • get_host() : возвращает хост клиента, для этого используется значения заголовков HTTP_X_FORWARDED_HOST (если включена опция USE_X_FORWARDED_HOST) и HTTP_HOST
  • get_port() : возвращает номер порта

  Например, получим некоторую информацию о запросе. Для этого в файле views.py :

  from django.http import HttpResponse def index(request): host = request.META["HTTP_HOST"] # получаем адрес сервера user_agent = request.META["HTTP_USER_AGENT"] # получаем данные бразера path = request.path # получаем запрошенный путь return HttpResponse(f""" 
  Host: 
  Path: 
  User-agent: """)

  В данном случае получаем два заголовка «HTTP_HOST» и «HTTP_USER_AGENT» и запрошенный путь.

  В файле urls.py зарегистрируем данную функцию:

  from django.urls import path from hello import views urlpatterns = [ path("index", views.index), ]

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

  Django использует request and response objects для передачи состояния через систему.

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

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

  HttpRequest objects

  class HttpRequest

  Attributes

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

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

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

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

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

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

  Например, если WSGIScriptAlias для вашего приложения имеет значение «/minfo» , то path может быть «/minfo/music/bands/the_beatles/» , а path_info — «/music/bands/the_beatles/» .

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

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

  HttpRequest.encoding

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

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

  Словарь параметров key/value включен в заголовок CONTENT_TYPE .

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

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

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

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

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

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

  Дополнительные сведения см. в Managing files .

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

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

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

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

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

  HttpRequest.headers — это более простой способ доступа ко всем заголовкам HTTP-prefixed, а также к CONTENT_LENGTH и CONTENT_TYPE .

  Нечувствительный к регистру объект, похожий на словарь, который обеспечивает доступ ко всем заголовкам HTTP-prefixed (плюс Content-Length и Content-Type ) из запроса.

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

  >>> request.headers >>> "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, заголовки также можно искать, используя символы подчеркивания вместо дефисов:

  HttpRequest.resolver_match

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

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

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

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

  Он будет использоваться в качестве корневого URLconf для текущего запроса, переопределяя настройку ROOT_URLCONF . Подробности см. в How Django processes a request .

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

  Он будет использоваться вместо DEFAULT_EXCEPTION_REPORTER_FILTER для текущего запроса. Подробности см. в Custom error reports .

  Он будет использоваться вместо DEFAULT_EXCEPTION_REPORTER для текущего запроса. Подробности см. в Custom error reports .

  Атрибуты, установленные промежуточным ПО

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

  Из SessionMiddleware : доступный для чтения и записи объект, похожий на словарь, который представляет текущий сеанс.

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

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

  if request.user.is_authenticated: . # Сделайте что-нибудь для зарегистрированных пользователей. else: . # Сделайте что-нибудь для анонимных пользователей. 

  Methods

  HttpRequest.get_host()

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

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

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

  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)

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

  HttpRequest.get_port()

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

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

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

  Возвращает абсолютный URI form 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)

  Возвращает значение файла 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' # предполагается, что cookie был установлен с использованием той же соли >>> 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 

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

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

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

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

  Большинство браузеров отправляют Accept: */* по умолчанию, поэтому для всех типов контента будет возвращено True . Установка явного заголовка Accept в API requests может быть полезна для возврата другого типа контента только для этих потребителей. См. Content negotiation example об использовании accepts() для возврата различного содержимого потребителям API.

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

  HttpRequest.read(size=None) HttpRequest.readline() HttpRequest.readlines() HttpRequest.__iter__()

  Методы, реализующие файловый интерфейс для чтения из экземпляра HttpRequest . Это позволяет обрабатывать входящий запрос в потоковом режиме. Распространенным вариантом использования будет обработка большой полезной нагрузки XML с помощью итеративного синтаксического анализатора без создания в памяти всего дерева XML.

  Учитывая этот стандартный интерфейс, экземпляр HttpRequest может быть передан непосредственно синтаксическому анализатору XML, такому как ElementTree :

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

  QueryDict objects

  class QueryDict

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

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

  Methods

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

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

  Создает объект QueryDict на основе query_string .

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

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

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

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

  classmethod QueryDict.fromkeys(iterable, value=», mutable=False, encoding=None)

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

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

  QueryDict.__getitem__(key)

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

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

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

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

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

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

  >>> q = QueryDict("a=1", mutable=True) >>> q.update("a": "2">) >>> q.getlist("a") ['1', '2'] >>> q["a"] # возвращает последний '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 имеет следующие методы:

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

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

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

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

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

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

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

  QueryDict.pop(key)

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

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

  QueryDict.popitem()

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

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

  QueryDict.dict()

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

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

  QueryDict.urlencode(safe=None)

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

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

  class HttpResponse

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

  Usage

  Passing strings

  Типичное использование — передать содержимое страницы в виде строки, байтовой строки или memoryview конструктору 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 = HttpResponse(b"Bytestrings are also accepted.") >>> response = HttpResponse(memoryview(b"Memoryview as well.")) 

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

  >>> response = HttpResponse() >>> response.write("
  Here's the text of the web page.
  ") >>> response.write("
  Here's another paragraph.
  ") 

  Passing iterators

  Наконец, вы можете передать 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 , поскольку эти поля могут иметь несколько значений, разделенных запятыми. Методы «заплаты» гарантируют, что другие значения, например, добавленные промежуточным программным обеспечением, не будут удалены.

  Поля заголовка 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, но синтаксис легко забыть, поэтому мы включили его сюда.

  Attributes

  HttpResponse.content

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

  Нечувствительный к регистру объект, похожий на словарь, который предоставляет интерфейс для всех заголовков HTTP в ответе. См. Setting header fields .

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

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

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

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

  Это всегда False .

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

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

  Methods

  HttpResponse.__init__(content=b», content_type=None, status=200, reason=None, charset=None, headers=None)

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

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

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

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

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

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

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

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

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

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

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

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

  Действует как dict.items() для заголовков HTTP в ответе.

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

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

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

  max_age должен быть объектом timedelta , целым числом секунд или None (по умолчанию), если файл cookie должен храниться только в течение сеанса браузера клиента. Если expires не указан, он будет рассчитан.

  Изменено в Django 4.1: Добавлена поддержка объектов timedelta .

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

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

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

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

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

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

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

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

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

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

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

  Всегда False . Этот метод превращает экземпляр HttpResponse в объект, подобный потоку.

  Всегда False . Этот метод превращает экземпляр HttpResponse в объект, подобный потоку.

  Всегда True . Этот метод превращает экземпляр HttpResponse в объект, подобный потоку.

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

  HttpResponse subclasses

  Django включает ряд подклассов HttpResponse , которые обрабатывают различные типы ответов HTTP. Подобно HttpResponse , эти подклассы живут в django.http .

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

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

  Подобно HttpResponseRedirect , но возвращает постоянное перенаправление (HTTP с кодом состояния 301 вместо «найденного» перенаправления (код состояния 302).).

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

  Действует так же, как HttpResponse , но использует код состояния 400.

  Действует так же, как HttpResponse , но использует код состояния 404.

  Действует так же, как HttpResponse , но использует код состояния 403.

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

  Действует так же, как HttpResponse , но использует код состояния 410.

  Действует так же, как 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 objects

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

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

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

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

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

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

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

  Usage

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

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

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

  Чтобы сериализовать объекты, отличные от dict , вы должны установить для параметра safe значение False :

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

  Без прохождения safe=False будет поднят TypeError .

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

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

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

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

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

  StreamingHttpResponse objects

  class StreamingHttpResponse

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

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

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

  Примером использования StreamingHttpResponse в WSGI является потоковая передача контента, когда генерация ответа занимает слишком много времени или использует слишком много памяти. Например, это полезно для generating large CSV files .

  Однако при этом есть соображения производительности. В2356069В, под Т1852789Т предназначен для недолговечных requests. Потоковые ответы привяжут рабочий процесс на все время ответа. Это может привести к снижению производительности.

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

  Однако при обслуживании под ASGI, StreamingHttpResponse не должен останавливать обслуживание других requests во время ожидания I/O.. Это открывает возможность долгоживущего requests для потоковой передачи контента и реализации таких шаблонов, как длительный опрос и события, отправленные сервером.

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

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

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

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

  Добавлена поддержка асинхронной итерации.

  Attributes

  StreamingHttpResponse.streaming_content

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

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

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

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

  Это всегда True .

  Новое в Django 4.2.

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

  Это полезно для промежуточного ПО, которому необходимо обернуть StreamingHttpResponse.streaming_content .

  FileResponse objects

  class FileResponse(open_file, as_attachment=False, filename=», **kwargs)

  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

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

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

  Methods

  FileResponse.set_headers(open_file)

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

  HttpResponseBase class

  class HttpResponseBase

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

  Похожие публикации:

  1. Как кастомизировать проводник в windows 10
  2. Как купить пуш уведомления
  3. Как пишется мэджик
  4. Как сделать домен третьего уровня