Работа с данными запроса

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

Поток ввода не имеет маркера конца файла. Если вы вызовете метод 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 - Прекратить чтение данных запроса, если любой не-файл поле формы больше этого количества байтов. В то время как части файлов могут быть перемещены на диск, обычные данные поля формы хранятся только в памяти и могут заполнить память. Значение по умолчанию составляет 500 КБ.
• max_form_parts - Прекратить чтение данных запроса, если отправлено более этого количества частей в данных multipart-формы. Это полезно для остановки очень большого числа очень маленьких частей, особенно частей файлов. По умолчанию значение равно 1000.

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

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

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

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

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