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

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

Отсутствие маркера 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().

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

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

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

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

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

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

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

Уже существует миксин, предоставляющий парсинг JSON:

from werkzeug.wrappers import Request
from werkzeug.wrappers.json import JSONMixin

class JSONRequest(JSONMixin, Request):
    pass

Базовая реализация выглядит так:

from werkzeug.utils import cached_property
from werkzeug.wrappers import Request
import simplejson as json

class JSONRequest(Request):
    @cached_property
    def json(self):
        if self.mimetype == "application/json":
            return json.loads(self.data)