Connection reset by peer problem.

Hi, we are using slumber to setup a smoke test against our server(django + uwsgi). We started to see this "connection reset by peer" error after we added the "content-length" in the response header. It only happens occasionally. However it never happens when we don't include content-length in the response header, at least based on our experiences. I see some similar questions about they all seem to related to ssl. We are just using http. Could anyone help? Thanks.

url: POST to http://127.0.0.1:8080/api/v1....

```
Traceback (most recent call last):
  File "./smoke_test_driver.py", line 936, 
    _pre_run_apis(host, cpe_mac, api_prefix, webpa_gateway, current_environment)
  File "./smoke_test_driver.py", line 790, in _pre_run_apis
    cpe.device_class.put({'xpc_model_class': device_class})
  File "/usr/local/lib/python2.7/site-packages/slumber/__init__.py", line 175, in put
    resp = self._request("PUT", data=data, files=files, params=kwargs)
  File "/usr/local/lib/python2.7/site-packages/slumber/__init__.py", line 97, in _request
    resp = self._store["session"].request(method, url, data=data, params=params, files=files, headers=headers)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 415, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', error(104, 'Connection reset by peer'))
```


Python will calculate the content-length for you. It's very likely your content-length is incorrect and that's causing your issue. Without more details about how to reproduce this, version information, or example code causing this, I'm very tempted to close this outright.


in our settings.py, we have

```
MIDDLEWARE_CLASSES = (
    'shared.audit_logging.middlewares.AuditLoggingMiddleware',  # other middleware
    'django.middleware.common.CommonMiddleware', # other middleware
    'shared.middlewares.http.ContentLengthMiddleware', # <== the middleware for content length
}
```

in http.py, the codes that put the content-length back to header is like this

```
class ContentLengthMiddleware(object):
    def process_response(self, request, response):
        if not response.streaming and not response.has_header('Content-Length'):
            response['Content-Length'] = str(len(response.content)) if response.content else '0'
        return response
```


@pcsysen Can you also print the headers on the response, as observed by requests?


@Lukasa I am sorry that I don't understand requests well enough. Could you show me how to do it? Thanks.


@pcsysen Sure:

``` python
r = requests.get(url)
print r.headers
```


@Lukasa Are you talking about the normal result? When it is working it is like this

```
Python 2.7.8 (default, Sep 30 2014, 22:34:31) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> r = requests.get('http://localhost:8080/api/v1/version')
>>> print r.headers
{'content-length': '728', 'content-type': 'application/json', 'allow': 'GET, HEAD, OPTIONS'}
```

I don't know if it tells anything. I was thinking maybe you want to see the header when the error happens, which I don't know and I failed to learn it from the example you posted.


Hang on, did you say the above is the output _without_ your `ContentLengthMiddleware`?


WITH  ContentLengthMiddleware.


Hmm. With `ConnectionResetByPeer`, I think uWSGI or your server will be at fault. Does uWSGI provide any output in these error cases?


No info at the uwsgi log.


Hmm. Can you provide some example code that reproduces the problem on your machine? I'll suggest edits to it that will give me some debugging information.


The thing is, it is a bit hard to reproduce. The error does not always happen.


@pcsysen Can you guarantee it'll happen _eventually_ if you put it in a `while True` loop?


I can't guarantee anything as I don't know why it happens. I have seen it happens 2 times today. I put it on a semi-loop. That is, I am also trying to debugging it myself by adding some debug printout. Every now and then, I stopped the loop and make some changes. The error did not happen within the last 2 hours.


@pcsysen is `response.content` always bytes? If not is it possible that the requests where you saw this had multi-byte characters in them? (To be clear, I'm fairly certain this isn't caused by requests at this point.)


@sigmavirus24 I don't quite understand what you mean by "always bytes". The response should be all ASCII characters.


@pcsysen It _should_ always be ASCII, but _is_ it?


@pcsysen Ping =)


Closing due to inactivity.


For anyone else having a 104 error, I seem to have fixed my problem by omitting gcc system includes.
I had used the output of `clang-3.6 -v -E -x c++ -` as my `-isystem` paths in `.ycm_extra_conf.py`, which output these two lines along with everything else:

```
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/include
```

It seems there are files in those paths whose content cause the 104 errors in Ycm, which is not surprising since there are lots of gcc intrinsics being declared.