# ECONNRESET error with HTTP.jl

**URL:** <https://discourse.julialang.org/t/econnreset-error-with-http-jl/11228>\
**Category:** Web Stack\
**Created:** [May 29, 2018, 11:33am UTC](https://discourse.julialang.org/t/econnreset-error-with-http-jl/11228 "2018-05-29T11:33:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [May 29, 2018, 11:33am UTC](https://discourse.julialang.org/t/econnreset-error-with-http-jl/11228/1 "2018-05-29T11:33:52Z")

</div>

I’m using HTTP.jl to POST data to a REST service, and every thirty minutes (it’s very regular), I’m hitting `ERROR: LoadError: IOError(read: connection reset by peer (ECONNRESET) during request`. Does that ring a bell to anybody? I can retry, and usually it works out, but it’s still a bit worrying.

Does HTTP.jl keep the connection to the server alive, or does it create a new connection on each request? My understanding of web protocols is fuzzy, so apologies if this is nonsensical 😛

---

<div class="post-metadata">

**Author:** ![dfdx](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dfdx/32/120_2.png) [@dfdx](https://discourse.julialang.org/u/dfdx)\
**Post date:** [May 29, 2018, 1:10pm UTC](https://discourse.julialang.org/t/econnreset-error-with-http-jl/11228/2 "2018-05-29T13:10:12Z")

</div>

It sounds like your REST server indeed closes the connection every 30 minutes. In HTTP 1.1, servers keep TCP connection alive for a short period of time (e.g. 30 seconds) by default in order to avoid repetitive TCP handshake. Normally, if you perform requests during this period the connection should be kept alive forever, but apparently your server has some hard deadline.

From the client size there isn’t much you can do: you either close connection every time by sending `Connection: close` header so that both - client and server - agree on the state, or simply do retries. From performance perspective the way you are doing it now is the most optimal.