EOF occurred in violation of protocol error about osfclient

[ctb]

I've investigated it a few times, for myself and others. It appears to be caused by an outdated version of openssl.

[theoutlander]

@nkmeyers I fixed this issue by running:

pip install pyopenssl

On OSX, the issue is related to python using the system OpenSSL which happens to be an outdated version.

Several people have faced this issue and there are a few things to try as listed on psf/requests#3006. In most cases, the above should solve the issue.

Here is another thread related to a similar issue: psf/requests#3391.

[ctb]

Ran into this again, pip install pyopenssl fixed it!

[ctb]

I ran into this while I was at COS, actually :). It's a problem with the installation of SSL on your mac, if I recall correctly. My solution (probably not the most parsimonious) was to upgrade openssl using homebrew. I will google about a bit and see if I can find something simpler.

[nkmeyers]

duh, I think I remember this old frustrater now, I'll piddle around w upgrading ssl but that's going to be an awkward fix to bake in to the osf-cli requirements for end-users so we may want another way around it? and in meantime I'll try it from a different terminal too.

[ctb]

you might try installing and using python3.6 -- but in any case all we can do is document the brokenness :). I don't think we want OSF to be using bad crypto, of course.

[nkmeyers]

okay I'm still on 2.7.13, I'll give that a go first! thx!

[benlindsay]

I'm on python 3.6 now, and I got a similar error as above. Here's what I saw while recursively uploading a directory:

Traceback (most recent call last):
  File "/home/lindsb/usr/miniconda/lib/python3.6/site-packages/requests/packages/urlli
b3/contrib/pyopenssl.py", line 438, in wrap_socket
    cnx.do_handshake()
  File "/home/lindsb/usr/miniconda/lib/python3.6/site-packages/OpenSSL/SSL.py", line 1
638, in do_handshake
    self._raise_ssl_error(self._ssl, result)
  File "/home/lindsb/usr/miniconda/lib/python3.6/site-packages/OpenSSL/SSL.py", line 1
371, in _raise_ssl_error
    raise SysCallError(-1, "Unexpected EOF")
OpenSSL.SSL.SysCallError: (-1, 'Unexpected EOF')

During handling of the above exception, another exception occurred:

And a few more similar errors showed up "during handling of the above exception". The error message didn't say what file it had an issue with, so I don't know how far the upload got before failing...

[betatim]

Also a Mac @benlindsay? Could you post the version of your OS. On my 10.11.16 (El capitan) it seems to work, at least I can't reproduce this. Another thing I can think of is: did you install openssl via brew?

[betatim]

A few results from googling:

• psf/requests#3965
• psf/requests#3337

They point to the TLS handshake not working. Either because the server is doing weird things or a proxy :-/

[benlindsay]

I'm on a campus research cluster with a lot of out-of-date software where I don't have root access. The result of uname -a is Linux rrlogin.internal 2.6.18-416.el5 #1 SMP Fri Oct 28 08:39:39 CDT 2016 x86_64 x86_64 x86_64 GNU/Linux and the result of lsb_release -a is

LSB Version:       :core-3.1-amd64:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-noarch
Distributor ID:	   ScientificSL
Description:	   Scientific Linux SL release 5.5 (Boron)
Release:           5.5
Codename:	   Boron

[betatim]

Let's collect a bit more data till we can figure out what the pattern is. If we figure out how to solve this -> solve it. Otherwise probably a good idea to catch this exception and print a useful message (once we know what that message should be)

[betatim]

I have openssl 1.0.2l on my mac, who can offer an earlier one that works?

Proposed error message: "Please update your version of openssl to at least version X"

[benlindsay]

I also have openssl 1.0.21 on my linux machine, so I don't think it's simply an openssl version issue. I'd guess that it has something to do with other old software that I don't have downloaded via Anaconda. My python modules are up-to-date.

[saurabhpilot]

Not able to resolve with above solutions

r = requests.post(url=url,headers=headers,data=json.dumps(Data),verify=False)
Traceback (most recent call last):
File "", line 1, in
File "/Library/Python/2.7/site-packages/requests/api.py", line 112, in post
return request('post', url, data=data, json=json, **kwargs)
File "/Library/Python/2.7/site-packages/requests/api.py", line 58, in request
return session.request(method=method, url=url, **kwargs)
File "/Library/Python/2.7/site-packages/requests/sessions.py", line 508, in request
resp = self.send(prep, **send_kwargs)
File "/Library/Python/2.7/site-packages/requests/sessions.py", line 618, in send
r = adapter.send(request, **kwargs)
File "/Library/Python/2.7/site-packages/requests/adapters.py", line 506, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='172.16.76.172', port=443): Max retries exceeded with url: /tssm/onboard-tenant (Caused by SSLError(SSLEOFError(8, u'EOF occurred in violation of protocol (_ssl.c:590)'),))

[heiniovason]

As @theoutlander and @ctb 'pip install pyopenssl' did the trick for me as well.

I had to make 30.000 requests asap., but I couldn't avoid being cut for by or the other SSL- or other connection error exception. If I was lucky the app ran 5 min without throwing an exception, and being cut off.
If I did added a sleep(0.5) before each request I was almost sure of not being cut off from this specific web service. Also added retry logic if I got an exception and with overhead jazz code to get things working reliably which I would rather not spend time doing.

After installing pyopenssl I've been starring like a happy child at console outputs :)

Environment is Python 3.5.2, and I'm using the requests library.