Известно, что nginx умеет сжимать ответ для передачи клиенту.
Но не смог найти информацию о обратной ситуации — приеме сжатого запроса.
Проблема вот в чем: мобильные клиенты передают много данных, и хотелось бы до того как gzip запрос дошел до пхп-бекенда, он был разархивирован и передан уже в чистом виде.
Во-первых, после того как вы распакуете тело запроса в nginx, то придется отравлять в php уже больший объем данных, соответственно больше операций копирования и, возможно, больше системных вызовов потребуется.
Во-вторых, на время распаковки nginx будет CPU-bound, его воркер не сможет выполнять свою прямую обязанность, как то обрабатывать соединения и запросы других пользователей.
В-третьих, nginx сначала принимает тело запроса в body buffer и если оно в нём не помещается, то складывает его на диск. С распаковкой всё становится ещё сложнее, потребуется ещё один буфер для распакованных данных, которых может быть в несколько раз больше и вероятность необходимости вовлечения диска — значительно возрастает. Кроме того, это создает вектор для атаки на nginx, поскольку передать можно килобайт, который будет пытаться распаковаться в несколько гигабайт. Он конечно осознает, что распакованный ответ превышает заданное ограничение, но для этого ему всё равно нужно будет сперва распаковать его хотя бы до этого ограничения, что для рабочего процесса nginx будет куда критичнее, чем для обработчика php, коих много.
Что касается php, то его производительность может оказаться хуже только по причине того, что в php с этим местом всё плохо, но это уже другой вопрос, решаемый вычеркиванием такого ЯП из своей головы и использованием более добротно сделанных инструментов, у которых и с fastcgi всё впорядке, и работа с памятью правильно реализована.
Насколько я знаю NGINX не распаковывает запросы с Content-Encoding: gzip…
Апече это умеет с помощью mod_deflate, а nginx — нет. Кстати хорошая идея для написания модуля. Поидее он не будет слишком сложным.