Технически спецификация WSGI не поддерживает концепцию мутирующих входных фильтров в качестве промежуточного программного обеспечения или даже на базовом веб-сервере.
Конкретная проблема заключается в том, что мутирующие входные фильтры изменят количество содержимого запроса, но не изменят значение CONTENT_LENGTH в словаре WSGI.
В спецификации WSGI указано, что действительное приложение WSGI разрешено считывать только с байтов CONTENT_LENGTH из содержимого запроса. Как следствие, в случае содержимого сжатого запроса, когда конечный размер запроса будет больше, чем указано в CONTENT_LENGTH, веб-среда, скорее всего, усекает ввод запроса до того, как все данные будут прочитаны.
Вы можете найти подробную информацию об этой проблеме в:
Хотя изменения в спецификации были отброшены на, ничего не произошло.
Чтобы решить эту проблему, вам необходимо выполнить промежуточное программное обеспечение WSGI, которое вы можете обернуть вокруг приложения Django, которое, если оно обнаруживает посредством переданных заголовков, что исходное содержимое было сжато, но где вы знаете, что Apache распаковал его, будет читать весь контент запроса до тех пор, пока он не достигнет конца маркера потока, игнорируя CONTENT_LENGTH, прежде чем даже передать запрос Django. Сделав это, он может затем изменить CONTENT_LENGTH и заменить wsgi.input на замещающий поток, который затем возвращает уже прочитанный контент.
Поскольку размер контента может быть довольно большим и неизвестного размера, чтение его в памяти не обязательно будет хорошей идеей. Поэтому вы, вероятно, захотите прочитать его в блоке за раз и записать его во временный файл. Затем wsgi.input будет заменен дескриптором открытого файла во временном файле, а CONTENT_LENGTH заменяется окончательным размером файла.
Если вы правильно изучаете архивы mod_wsgi в Google Groups, вы должны найти предварительные обсуждения этого и, возможно, даже некоторого примерного кода.