unexpected keyword argument 'buffering' - python client

You seem to be unfamiliar with Python 3. It introduced a new style of tracebacks so that you can best figure out which path through your code was taken so you can potentially find the source of the final exception. Let's examine your traceback:

 Traceback (most recent call last):   File "C:\Kivy180\Python33\lib\site-packages\requests-2.2.1-py3.3.egg\requests\packages\urllib3\connectionpool.py", line 313, in _make_request     httplib_response = conn.getresponse(buffering=True) TypeError: getresponse() got an unexpected keyword argument 'buffering' During handling of the above exception, another exception occurred:

The important thing here is the very last line: "During handling of the above exception, another exception occurred:". This indicates that TypeError: getresponse() got an unexpected keyword argument 'buffering' was not the source of the exception that stopped your program, but it was in fact being handled when a different exception occurred.

You'll now notice that "During handling of the above exception, another exception occurred:" occurs a few more times in the output you pasted and the final trace ends with:

File "C:\Kivy180\Python33\lib\site-packages\requests-2.2.1-py3.3.egg\requests\adapters.py", line 378, in send raise ConnectionError(e)requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=9624): Max retries exceeded with url:/BasicServ.svc/auth/Authorize/admin/1234(Caused by <class 'ConnectionResetError'>:    [WinError 10054] An existing connection was forcibly closed by the remote host)

I've broken up this last line to be more readable (so it doesn't scroll off to the side). The exception you're seeing is caused by the server forcibly closing a connection that was open. I would normally expect to see this if you were using a Session object because that does connection pooling for you by default, but you're using the functional API which creates a new Session object each time. This means that the server here is most likely misbehaving if this is happening repeatedly. The server is refusing to respond to your request and forcibly closing the connection that was made. While trying to read the response urllib3 receives the WinError exception from which there is no good way to recover other than providing it's own exception ConnectionResetError. Requests then catches this and raises it's own ConnectionError.

The problem here does not seem to be requests, but instead a misbehaving server.

On a side note, having the username and password in a URL is a very bad idea. I would advise investigating using HTTP Digest Authentication, HTTP Basic Authentication, or implementing something more secure (like a token based authentication scheme).