Мы разрабатываем веб-сервис Python и клиентский веб-сайт параллельно. Когда мы делаем HTTP-запрос от клиента к сервису, один вызов постоянно вызывает socket.error в socket.py, в read:
(104, 'Connection reset by peer')
Когда я слушаю Wireshark, ответы «хорошо» и «плохо» выглядят очень похоже:
- Из-за размера заголовка OAuth запрос разбивается на два пакета. Служба отвечает как ACK
- Служба отправляет ответ, один пакет на заголовок (HTTP / 1.0 200 OK, затем заголовок Date и т. Д.). Клиент отвечает каждому ACK.
- (Хороший запрос) сервер отправляет FIN, ACK. Клиент отвечает FIN, ACK. Сервер отвечает ACK.
- (неверный запрос) сервер отправляет RST, ACK, клиент не отправляет ответ TCP, на стороне клиента возникает ошибка socket.error.
И веб-служба, и клиент работают на коробке Gentoo Linux x86-64 с glibc-2.6.1. Мы используем Python 2.5.2 внутри того же virtual_env.
Клиент - это приложение Django 1.0.2, которое вызывает httplib2 0.4.0 для выполнения запросов. Мы подписываем запросы с помощью алгоритма подписи OAuth, для маркера OAuth всегда задана пустая строка.
Служба работает под управлением Werkzeug 0.3.1, который использует Python wsgiref.simple_server. Я без проблем запустил приложение WSGI через wsgiref.validator.
Кажется, что это должно быть легко отладить, но когда я прослеживаю хороший запрос на стороне службы, он выглядит как неправильный запрос в функции socket._socketobject.close (), превращая методы делегата в фиктивные. методы. Когда метод send или sendto (не помню, какой) отключен, отправляется FIN или RST, и клиент начинает обработку.
"Сброс соединения по пиру", кажется, возлагает вину на службу, но я тоже не доверяю httplib2. Может ли клиент быть виноват?
** Дальнейшая отладка - похоже на сервер в Linux **
У меня есть MacBook, поэтому я попытался запустить службу на одном, а веб-сайт клиента - на другом. Клиент Linux вызывает сервер OS X без ошибки (FIN ACK). Клиент OS X вызывает службу Linux с ошибкой (RST ACK и a (54, «Сброс соединения по пиру»). Похоже, это сервис, работающий в Linux. Это x86_64? Плохой бойц? wsgiref? Все еще смотрю ...
** Дальнейшее тестирование - wsgiref выглядит ненадежно **
Мы перешли на работу с Apache и mod_wsgi, и сброс соединений прекратился. Смотрите мой ответ ниже, но мой совет - зарегистрировать сброс соединения и повторить попытку. Это позволит вашему серверу нормально работать в режиме разработки и стабильно работать.