Несколько 100-продолжений получено с сервера

Я использую библиотеку libcurl (c ++), чтобы сделать запрос к серверу IIS 7.5. Транзакция является обычной веб-службой SOAP.

Все работает нормально, мои запросы отправляют флаг «Ожидается 100-продолжение», и сервер отвечает 100-продолжением и сразу после этого кодом 200 ok вместе с ответом веб-службы.

Но время от времени клиент получает сообщение 100-continue и после этого еще один код 100. Это заставляет клиента сообщать об ошибке, поскольку он ожидает окончательный код состояния сразу после кода сервера 100. Я прочитал в протоколе W3C HTTP1.1:

Исходный сервер, который отправляет ответ 100 (продолжение), ДОЛЖЕН
в конечном итоге отправить окончательный код состояния, как только тело запроса
получен и обработан, если это не прекращает транспортировку
преждевременное соединение.

Слово «в конечном счете» заставляет меня потерять след. Возможно / распространено ли, что сервер отправляет несколько 100 кодов после окончательного кода состояния?

Если кто-то сталкивался с этой проблемой раньше, можете ли вы указать мне любое объяснение о том, как обрабатывать несколько 100 кодов ответов с помощью libcurl?

заранее спасибо

3

Решение

Текущая спецификация говорит этот на 100-продолжайте:

Код состояния 100 (Продолжить) указывает, что начальная часть
запрос был получен и еще не был отклонен сервером. Сервер намеревается отправить окончательный ответ после того, как запрос будет полностью получен и обработан.

Когда запрос содержит поле заголовка Expect, которое включает
100 — ожидание продолжения, ответ 100 указывает, что сервер желает получить тело полезной нагрузки запроса, как описано в
Раздел 5.1.1. Клиент должен продолжить отправку запроса и отменить ответ 100.

Если запрос не содержал поле заголовка Expect, содержащее ожидание 100-продолжений, клиент может просто отбросить этот промежуточный ответ.

То, как я это прочитал, не должно быть более одного 100-заголовочного ответа, и поэтому libcurl работает так. Я никогда не видел, чтобы это произошло (несколько сотен ответов), и некоторое время я занимался HTTP (я главный разработчик curl). Чтобы изменить это поведение, я ожидаю, что вам нужно будет немного исправить патч libcurl, чтобы это произошло.

это не связанные с CURLOPT_FAILONERROR.

2

Другие решения

Я подозреваю, что это потому, что есть необработанная ошибка, которая не обрабатывается клиентом должным образом. Убедитесь, что вы установили CURLOPT_FAILONERROR флаг.

Увидеть этот ТАК пост для дополнительной информации.

0

По вопросам рекламы [email protected]