Обработка данных запроса

Отсутствие маркера EOF в потоке ввода

Поток ввода не имеет маркера конца файла. Если вы вызовете метод read() на потоке wsgi.input, ваше приложение зависнет на серверах, соответствующих спецификации. Однако это сделано намеренно, хоть и болезненно. Werkzeug решает эту проблему, обернув поток ввода в специальный LimitedStream. Поток ввода доступен в объектах запроса как stream. Этот поток либо пустой (если данные формы были обработаны), либо ограниченный поток с содержимым потока ввода.

Когда Werkzeug обрабатывает данные?

Werkzeug обрабатывает входящие данные в следующих ситуациях:

• вы обращаетесь к form, files, или stream, а метод запроса был POST или PUT.
• если вы вызываете parse_form_data().

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

Это также верно, если вы читаете из потока wsgi.input до обработки.

Общее правило: Оставьте поток ввода WSGI в покое. Особенно в WSGI-средах. Используйте либо функции обработки, либо объект запроса. Не смешивайте несколько библиотек WSGI для разбора данных форм или чего-либо ещё, что работает с потоком ввода.

Как происходит обработка?

Стандартное поведение обработки Werkzeug обрабатывает три случая:

• тип содержимого входных данных был multipart/form-data. В этой ситуации stream будет пустым, а form будет содержать обычные данные POST / PUT, а files будет содержать загруженные файлы в виде объектов FileStorage.
• тип содержимого входных данных был application/x-www-form-urlencoded. Тогда stream будет пустым, а form будет содержать обычные данные POST / PUT, а files будет пустым.
• тип содержимого входных данных не соответствовал ни одному из них, stream указывает на LimitedStream с данными ввода для дальнейшей обработки.

Особое замечание по методу get_data: Вызов этого метода загружает все данные запроса в память. Это безопасно только в том случае, если параметр max_content_length установлен. Кроме того, вы можете либо прочитать поток, либо вызвать get_data().

Ограничение данных запроса

Класс Request предоставляет несколько атрибутов для управления тем, сколько данных из тела запроса обрабатывается. Это может помочь смягчить атаки DoS, которые создают запрос таким образом, что сервер использует слишком много ресурсов для его обработки. Каждое из этих ограничений вызовет RequestEntityTooLarge, если они будут превышены.

• max_content_length Прекратить чтение данных запроса после этого количества байтов. Лучше настроить это в сервере WSGI или HTTP-сервере, а не в приложении WSGI.
• max_form_memory_size Прекратить чтение данных запроса, если какой-либо элемент формы превышает это количество байтов. Хотя части файлов могут быть перемещены на диск, обычные данные полей формы хранятся только в памяти.
• max_form_parts Прекратить чтение данных запроса, если в данных multipart-формы отправляется более этого количества частей. Это полезно для остановки очень большого количества очень маленьких частей, особенно файловых частей. По умолчанию значение равно 1000.

Использование Werkzeug для установки этих ограничений — лишь один уровень защиты. Серверы WSGI и HTTPS-серверы должны устанавливать свои собственные ограничения по размеру и таймаутам. Операционная система или менеджер контейнеров должны устанавливать ограничения на память и время обработки для процессов сервера.

Если ошибка 413 Content Too Large возвращается до чтения всего запроса, клиенты могут показать ошибку «разрыв соединения» вместо ошибки 413. Это основано на том, как сервер WSGI/HTTP и клиент обрабатывают соединения, и это не то, над чем WSGI-приложение (Werkzeug) имеет контроль.

Как расширить обработку?

Современные веб-приложения передают гораздо больше, чем данные multipart-форм или закодированные по URL. Для расширения возможностей, подклассифицируйте Request или Request и добавьте или расширьте методы.