Anyone else having this problem today?

Admittedly I'm downloading quite a lot of player (stats) endpoints this afternoon but I can 't remember getting this particular error before - can anyone throw any light on it? ....

#

  File "C:\Users\Stephen\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\api.py", line 75, in get
    return request('get', url, params=params, **kwargs)
  File "C:\Users\Stephen\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\api.py", line 61, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\Users\Stephen\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\sessions.py", line 542, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\Users\Stephen\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\sessions.py", line 655, in send
    r = adapter.send(request, **kwargs)
  File "C:\Users\Stephen\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\adapters.py", line 514, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='api.chess.com', port=443): Max retries exceeded with url: /pub/player/dhiego/stats (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:1129)')))

#

My knowledge of ftp is next to zero which is why I rely on the Python Requests module to take care of that for me but this is starting to slow me down quite seriously. Might it be due to overloaded servers? Usually see 50* errors for that.

I pressed on after the first two but when the third one made my program crash I thought it was time to ask.....

Just tried that users stats address and got full returns without any errors. (Excel spreadsheet, not python)

Yes, me too. None of the three usernames involved failed a second attempt, so I'm thinking it's more to do with the interchange of ftp data between my requests module and the server but that's way beyond any expertise I possess.

It's working fine at the moment and I'm almost finished and what I'm doing is usually a twice in the year task, so not a huge inconvenience. I don't usually provide error trapping for very uncommon exceptions and maybe I should but like many unusual ones it's hard to decide what's worth providing for and what isn't.

In the past, I think they have done maintenance on the API server on a Sunday. Maybe just that causing intermittent issues.

I have a standard routine that I pass the API address to and returns a data string, All the error trapping is in it so happens every time.

I have something similar but it only separates those returns that are successful (status = 200) from those that aren't (404, 410 and of course the site's annoying 502's) but all of those invo;ve successful two-way communication.

I can't ever remember the requests module itself generating any error message due to a handshake problem.

Possibly but I'd expect any properly organised maintenance to (at worst) restrict access, giving some kind of generic server return - status 500 maybe?

What I'm getting seems more circuit-level, down in the silicon so to speak 😄

The good news is that I managed to finish what I was doing without any more failures. It would be nice to know though what was going wrong there?

But I'll make a mental note to avoid Sundays in future when I'm making a large number of requests.