запросы.исключения.Ошибка подключения: (‘Соединение прервано.’, RemoteDisconnected(‘Удаленное конечное закрытое соединение’)) в python request.api

#python-3.x #python-requests

#python-3.x #python-запросы

Вопрос:

 import requests

resp = requests.api.post(url,headers=self.headers,data=json.dumps(data))
 

при запуске в jenkins иногда он работает нормально, но в других случаях выдает ошибку ниже

 requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
 

Комментарии:

1. У меня была точно такая же ошибка раньше! Я думаю, это может быть сервер?

Ответ №1:

Ваш .post() вызов правильный.

Сервер поврежден и / или ваши данные неправильно сформированы, что приводит к нарушению работы сервера. (Я бы ожидал 400 или 500 от сервера.)

Убедитесь, что подключение по протоколу TCP / IP является хорошим, например, с $ telnet host 443 помощью .

Убедитесь, что data это нормальная длина — отправка гигабайт не сделает вас счастливыми.

Редактировать

Теперь вы говорите, что это детерминированное поведение: 1-й работает, 2-й терпит неудачу. Это говорит о том, что кэширование соединения имеет значение. Модуль запросов поддерживает пул открытых TCP-подключений к веб-серверам на случай, если в ближайшее время поступит другой запрос.

Возможно, вы опубликовали сообщение, сервер сказал 201 , что создано или что-то еще, а также сказал, что клиент должен закрыть соединение после считывания статуса. Но клиент не закрыл соединение и с удивлением обнаружил, что серверная часть закрыта при попытке 2-го сообщения по тому же соединению.

Вы запускаете:

 resp = requests.api.post(url, ...)
 

Вместо этого вы могли бы использовать:

 sess = requests.Session()
resp = sess.post(url, ...)
 

Тогда у вас будет контроль над тем, когда следует отказаться от пула сеансовых подключений и создать новый.

Комментарии:

1. но он отлично работает для одних и тех же данных один раз и выдает прерывание соединения в другой раз.

2. я реализовал это, но все же я столкнулся с вышеупомянутой проблемой прерывания соединения, есть ли какой-либо другой способ преодолеть

3. Вы еще не определили, почему сервер ведет себя так, как он. Без диагностики основной причины внесение случайных изменений в поведение клиента вряд ли улучшит ситуацию. Проверьте уровень журнала на обоих концах. Используйте wireshark для просмотра сведений об http.