Как сделать chunked запрос через nginx

Question

Кажется, что nginx не поддерживает упорядоченные запросы. Но я пытаюсь получить более окончательный (и текущий) ответ. У меня есть клиент, делающий SOAP-запрос на сервер с Java-клиента, который устанавливает заголовок Transfer-Encoding: chunked. Все работает хорошо, когда я подключаюсь непосредственно к моему приложению на Tomcat.

Но когда я устанавливаю nginx между ними, тогда все ломается.

Чтобы добавить несколько деталей: я работаю с CloudFoundry. Я использую Micro Cloud Foundry, чтобы подтвердить, что все работает так, как ожидалось, в отсутствие nginx. Но мое требование - использовать cloudfoundry.com, поэтому у меня нет возможности обходить nginx там.

This question and answer говорит, что это, пожалуй, только мое решение: http://wiki.nginx.org/NginxHttpChunkinModule. Но обходной путь недоступен, так как я не могу изменить конфигурацию на cloudfoundry.com.

This question также выглядит аналогичным, но на самом деле это перекрывает это требование. Он охватывает ответы, а не частые запросы.

Итак, как насчет каких-либо изменений на клиенте, чтобы обойти это? Можно ли отправить как Transfer-Encoding: chunked, так и Content-Length: 123 в качестве заголовков? Эта область для меня новая, но, похоже, из таких проектов, как Apache HttpComponents, можно задать либо длину, либо фрагмент, но не оба. Точка прерывания состоит в том, что вам не нужно знать длину при запуске запроса. Могу ли я сказать, что мой клиент использует HTTP/1.0 и хорошо играет с nginx без chunking? Есть ли другие обходные идеи, которые я забываю?

Answer 1

Я собрал ответы на все части этого вопроса.

База nginx не поддерживает запрошенные запросы (как подтвердил Александр!). Nginx может поддерживать запрошенный запрос, используя NginXHttpCunkinModule (как упоминается в моем вопросе). Лучше: этот модуль окончил бета-статус до качества продукции более 18 месяцев назад. Лучшее: я говорил с некоторыми членами инженерной команды CloudFoundry в недавнем meetup; они подтверждают, что планируется добавить этот модуль в свою версию nginx. Задача решена. (Ну, он полностью решен в долгосрочной перспективе, но у нас нет точной даты, когда ожидать этого.)

Поэтому краткосрочное решение было бы неплохо. Я нашел его.

Ответ на мой вопрос, адресованный Александру: Невозможно отправить «Content-Length» с помощью помеченных сообщений. На самом деле это точка разнесенных сообщений: вы начинаете отправлять их до того, как будете иметь полный контент, поэтому вы не можете знать длину. Поэтому его идея избежать частых запросов правильна. Но, чтобы быть более практичным, я бы сказал: «Используйте HTTP/1.0, а не HTTP/1.1». Это приводит к тому, что вы не отправляете помеченные сообщения. Мы смогли временно исправить наш клиент, чтобы проверить эту идею. Это сработало. Но мы не планируем выпускать публичный патч. Кажется контрпродуктивным заставить всех использовать десятилетний протокол (и 10-летнюю неподдерживаемую клиентскую библиотеку!), Чтобы решить проблему для этой ситуации.

Вместо этого я буду использовать взломанный клиент, когда потребуется, я отправлю по электронной почте, если другие найдут для этого необходимость, и мы будем ждать обновления CloudFoundry до HttpChunkin и HTTP/1.1.

Answer 2

Nginx на самом деле не поддерживает запрошенные запросы. Он вернет 411 Content Length required в отсутствие заголовка .

Поскольку вы контролируете свой код клиента, я думаю, что единственный вариант - избежать использования фрагментированных запросов и указать явно Content-Length.