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

Самое важное правило веб-разработки — «Не доверяйте пользователю». Это особенно актуально для данных входящих запросов на потоке ввода. С WSGI это на самом деле немного сложнее, чем вы ожидаете. По этой причине Werkzeug оборачивает поток запроса, чтобы избавить вас от наиболее распространённых проблем с ним.

Отсутствие маркера конца файла в потоке ввода

Поток ввода не имеет маркера конца файла. Если вы вызовете метод 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().

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

Чтобы избежать атаки DDOS, вы можете установить максимальный объём принимаемого содержимого и размеры полей запроса. Класс Request имеет для этого два атрибута: max_content_length и max_form_memory_size.

Первый можно использовать для ограничения общего объёма содержимого. Например, установив его в 1024 * 1024 * 16, запрос не примет более 16 МБ переданных данных.

Поскольку некоторые данные нельзя перенести на жёсткий диск (обычные данные POST), в то время как временные файлы можно, есть второе ограничение, которое можно установить. max_form_memory_size ограничивает размер POST переданных данных формы. Установив его в 1024 * 1024 * 2, можно убедиться, что все хранящиеся в памяти поля не превышают 2 МБ.

Однако это не влияет на хранящиеся в памяти файлы, если используемый stream_factory возвращает файл в памяти.

Как расширить парсинг?

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