#java #http #curl #apache-httpclient-4.x #apache-httpcomponents
Вопрос:
У меня есть сервлет, который использует Http-клиент Apache для выполнения запросов к третьей стороне. Это работало в течение многих лет, но я добавляю новую третью сторону, которую я вызываю через существующий сервлет. Он выходит из строя (404) из сервлета, но отлично работает с помощью командной строки curl с той же машины.
Действительно странно то, что он работает против этой сторонней системы песочницы, как из curl, так и из сервлета. Единственное различие, которое я вижу в выводе curl между двумя случаями, заключается в том, как 100% возвращается со стороннего сервера. Когда я вызываю сервер песочницы (который также работает от Http-клиента), возвращаемые заголовки выглядят так:
< HTTP/1.1 100 Continue
< HTTP/1.1 200
Когда я вызываю систему тестирования/контроля качества (которая работает из curl, но не из Http-клиента) , эквивалентные строки
< HTTP/1.1 100
< HTTP/1.1 200
Как вы можете видеть, тот, который работает, возвращается 100 Continue , а тот, который не работает, просто возвращается 100 . Насколько я понимаю, включение сообщения в статус рекомендуется, но необязательно, так что это соответствует стандарту. И я не получаю исключения, я получаю страницу 404 с текстом HTML, который явно исходит от этой третьей стороны.
Я попытался активировать «проводное» ведение журнала (в соответствии с их документацией — мы используем log4j, поэтому добавили его в существующий файл свойств), но не получили никакого дополнительного ведения журнала вообще. Вот почему я использую curl, чтобы попытаться увидеть разницу в том, как реагирует третья сторона.
Я попытался отключить всю функцию 100-продолжить ( .setExpectContinueEnabled(false) при создании моей RequestConfig ), но это не помогло (curl также работает и без функции 100-продолжить)
Происходит ли сбой Http-клиента Apache каким-то странным образом, если 100 сообщение не включено? Или я сосредотачиваюсь совсем не на том месте?
(Мы все еще используем ветвь 4.5.x Http — клиента Apache- я обновлен до последней версии 4.5.13. Я могу попробовать серию 5.x.x, но это повлияло бы на гораздо большее, я думаю)
Комментарии:
1. Оно делает. Ваша проблема вряд ли будет связана с сообщением о состоянии, не имеющим причины.
Ответ №1:
Оказывается, клиент прекрасно справляется с 100 этим без сообщения.
Проблема заключалась в третьей части, которая работала https://api.example.com/foo , но давала 404 за https://api.example.com:443/foo ! Не спрашивай…
curl Команда включала порт, но керл, должно быть, удалил его, так как он был стандартным. Изменил свой сервлет, чтобы сделать это, и это сработало.