Requests: socket.error:[Errno54]ピアによって接続がリセットされました

作成日 2011年09月22日  ·  19コメント  ·  ソース: psf/requests

私は現在、エラーを取得していますsocket.error: [Errno 54] Connection reset by peer 、私が使用したときにrequests.get(url, params=kwargs)paramsテキストの大きな体が含まれています。 2つの大きなテキストをそれぞれ2,900文字未満に切り捨てると、機能します。 curlを使用してコマンドラインから同じgetリクエストを実行すると、機能します。 pip install python-requestsを使用してインストールしたリクエストバージョン0.6.1を使用しています。

python-sendgridライブラリを使用してsendgridアカウントにニュースレターを追加していて、APIユーザー名とパスワードを問題チケットに投稿したくないため、問題を再現するように指示する方法がわかりません。 :)

curlを使用してコマンドラインからテストするために、urlencoderを使用してurlencodedされたプレーンテキストとhtmlテキストをそれぞれ含む2つのファイルを作成しました。 次に、次のコマンドを実行しました。

export IDENTITY='<my identity number>'
export API_KEY='<my smtp password>'
export API_USER='<my smtp username>'
export NAME='<My Urlencoded Newsletter Name>'
export SUBJECT='<My Urlencoded Newsletter Subject>'
TEXT=`cat urlencoded.txt`; HTML=`cat urlencoded.html`; curl -d "api_user=$API_USER&api_key=$API_KEY&identity=$IDENTITY&name=$NAME&subject=$SUBJECT&text=$TEXT&html=$HTML" https://sendgrid.com/api/newsletter/newsletter/add.json

最も参考になるコメント

甘いアクション! requests.get(url, params=kwargs)からrequests.post(url, data=kwargs)切り替えると、修正されました。 ご迷惑をおかけして申し訳ありません。助けてくれてありがとう!

全てのコメント19件

うーん、面白い。 それが発生しているエラーである場合、サーバーが実際に接続をリセットしていないと信じる理由はほとんどありません。

CharlesのようなHTTPプロキシを利用できますか? それは実際に何が起こっているのかを明らかにするのに役立つかもしれません。

申し訳ありませんが、完全なトレースバックを提供するのを忘れました。 エラーが発生したときに取得するトレースバックは次のとおりです。 また、HTTPプロキシの使用方法と、curlを使用してコマンドラインから機能する場合にそれが違いを生む理由がわかりません。

Traceback (most recent call last):
  File "/Users/oconnor/.virtualenvs/emails/bin/django-admin.py", line 5, in <module>
    management.execute_from_command_line()
  File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/__init__.py", line 429, in execute_from_command_line
    utility.execute()
  File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
    output = self.handle(*args, **options)
  File "/Users/oconnor/Sites/wenworld/emails/emails/management/commands/ww_daily_headlines_send.py", line 114, in handle
    self.add_newsletter_to_sendgrid(sendgrid_newsletter_name, NEWSLETTER_SLUG)
  File "/Users/oconnor/Sites/wenworld/emails/emails/management/commands/ww_daily_headlines_send.py", line 94, in add_newsletter_to_sendgrid
    html=email.html
  File "/Users/oconnor/.virtualenvs/emails/src/sendgrid/src/sendgrid/__init__.py", line 67, in newsletter_add
    subject=subject, text=text, html=html)
  File "/Users/oconnor/.virtualenvs/emails/src/sendgrid/src/sendgrid/__init__.py", line 157, in get
    return self.call(method, **kwargs)
  File "/Users/oconnor/.virtualenvs/emails/src/sendgrid/src/sendgrid/__init__.py", line 56, in call
    result_json = json.loads(response.content)
  File "/Users/oconnor/.virtualenvs/emails/lib/python2.7/site-packages/requests/models.py", line 429, in __getattr__
    self._content = self.read()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 351, in read
    data = self._sock.recv(rbufsize)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 553, in read
    s = self.fp.read(amt)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1276, in read
    return s + self._file.read(amt - len(s))
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 380, in read
    data = self._sock.recv(left)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 219, in recv
    return self.read(buflen)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 138, in read
    return self._sslobj.read(len)
socket.error: [Errno 54] Connection reset by peer

githubから返される応答は...

<html>
<head><title>414 Request-URI Too Large</title></head>
<body bgcolor="white">
<center><h1>414 Request-URI Too Large</h1></center>
<hr><center>nginx/0.7.65</center>
</body>
</html>

前に述べたように、 curlで動作するので、これは奇妙です。

チャールズ(または同様のもの)を介して2つのリクエストを確認する時間をとれば、問題はすぐにわかると思います。


エラーが示すように、Request-URIはサーバーが処理するには大きすぎるため、接続を切断しています。

リクエストでは、すべてのデータをリクエストURIの大規模なクエリ文字列として送信します。これはGETパラメータと呼ばれます。 curlを使用している場合は、フォームにエンコードされたデータをリクエストの本文にアップロードします。これはPOSTデータと呼ばれます。

requests.get(url, params=kwargs)requests.post(url, params=kwargs)両方を使用しようとしましたが、どちらも同じエラーを返します。 何らかの理由で、Charlesはcurlからのリクエストをキャプチャしておらず、ブラウザとpython-requestsを使用するpythonコマンドラインスクリプトからのリクエストをキャプチャしているだけです。

心配ない。

paramsはクエリ文字列用、 dataはPOSTデータ用です。

甘いアクション! requests.get(url, params=kwargs)からrequests.post(url, data=kwargs)切り替えると、修正されました。 ご迷惑をおかけして申し訳ありません。助けてくれてありがとう!

全く心配ありません:)

同様のデータで同じエラーが発生するのは不思議です。唯一の違いは、私の場合、パラメータの大きなリストやサイズがないことです。 CURLを介して行われた同じリクエストは正常に機能しますが、リクエストを介してこのエラーが発生します。

requests.exceptions.ConnectionError:HTTPSConnectionPool(host = 'sbarnea.com'、port = 443):URLで最大再試行回数を超えました:/ jira / rest / api / 2 / group?groupname = jira-administrators&expand = users(原因::[Errno 54]ピアによって接続がリセットされました)

さらに興味深いことに、リクエストはWebサーバーにも届かないようです。

それが何を引き起こす可能性があるのか​​考えていますか?

@ssbarneaこの問題は2年以上前のものです。現在発生している問題とは、何の関係もありません。 =)問題を追跡するために新しい問題を開くことができますか?

さらに良いことに、問題を開かないで、StackOverflowに話しかけてください。質問をしているので、リクエストの動作に問題があると信じる理由はありません。 StackOverflowで詳細をハッシュ化すると、バグレポートを提出できます(必要な場合)。

これは非常に奇妙な動作であり、リクエストのバグではないと信じる理由があります。そのため、新しいバグを開きました。 私はまだこれを引き起こす可能性のあるものを調査しています、それは私のマシンからのみ起こります、しかし最も興味深い部分はCURLが機能することです(そしてブラウザも)。 ありがとうございました。

これをここに保管して申し訳ありませんが、私はこれを引き起こす原因を見つけました:

#  resolver 127.0.0.1;
#  ssl_protocols TLSv1.2 TLSv1.1 ; # TLSv1
#  ssl_stapling on;
#  ssl_stapling_verify on;
#  ssl_session_cache builtin:1000;
#  ssl_session_timeout 30m;
#  ssl_ciphers HIGH:!RC4:!aNULL:!MD5;
#  ssl_prefer_server_ciphers on;

nginxサーバーでこれらの調整を無効にすることで、リクエストの処理を開始しました。明らかに、そのうちの1つが誤動作を引き起こしています。

@ssbarnea
#1567(およびその他いくつか)で説明されているような特定のSSL / TLSバージョンで話されたときに、バグのあるサーバーが間違ったことをしている可能性があります。
ここで説明さ

そして勝者(敗者)はssl_protocols TLSv1.2 TLSv1.1;
サーバーでサポートされているプロトコルからTLSv1を削除すると、リクエストが機能しなくなるようです。

今、私はこれをリクエストまたは基礎となるライブラリのバグと呼ぶことができますか?

注:セキュリティ上の懸念からTLSv1の削除をお勧めします。これには、悪用があります。

@ssbarnea制限はリクエストではなく、Pythonにあることがわかります。 現在、出荷されたバージョンのPythonは、ここの表に示されているように、V1.0より新しいバージョンのTLSをサポートしていません。

Python 3.4(まだ出荷されていません。Requestsとの互換性は保証されていません)では、TLS1.2およびTLS1.1のサポートが許可されているため、試してみることができます。 それ以外の場合は、TLSv1がリクエストを通過できるようにする必要があります。

それでも奇妙なことがあります。どちらの場合もPythonを使用しましたが、OS Xからテストすると失敗し、Ubuntuからテストすると機能しました。

通常、SSLのデフォルト設定には触れませんが、SSLレポートを実行して、ほとんどの警告を解決しようとしました。

FIPSに必要なもの:SSLv2およびSSLv3が無効になっている(使用中のTLSバージョンプロトコルのみ)
BEAST攻撃についても読んでください。

ここでそれをチェックしてください:
https://sslcheck.globalsign.com/en_US/sslcheck/?host=sbarnea.com

したがって、これを修正することは可能かどうか疑問に思います。明らかに、Ubuntu上のPythonで動作する場合、すべてのPythonバージョンに固有であるとは限りません。

うーん、悲しいことにそれはできます。 取得するsslサポートの相対的な機能は、インストールしたOpenSSLのバージョンによって異なります。 2つのバージョンを比較します。 =)

この件について少し締めくくります。 WebサーバーでTLSv1が許可されていない場合は、Python 2.7.9でTLSv1.1および1.2を入手できます(2014年12月にリリース予定)。 ただし、PYOpenSSLをインストールして、それをurrlib3(http://urllib3.readthedocs.org/en/latest/security.html#openssl-pyopenssl)に挿入することもできます。これにより、PythonでTLSv1を無効にしたWebサーバーへのリクエストを使用できるようになります。 2.7.6(およびおそらく他の人)。

import urllib3.contrib.pyopenssl
urllib3.contrib.pyopenssl.inject_into_urllib3()

しかし実際には、Webサーバーは、人々にこの多くの奇妙なフープを飛び越えさせるようなものを非推奨にするべきではありません。

このページは役に立ちましたか?
0 / 5 - 0 評価