-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connection reuse failure when go-ipfs node called from Swift API client. #3767
Comments
I tried a small experiment with a bunch of I will have to run some experiments with running |
On 0.4.6? |
@NeoTeo any update on this? |
@Kubuxu Not from me. I got the impression @whyrusleeping was going to run some |
Yeah, i still havent done that :/ |
@NeoTeo Havent done this with |
@NeoTeo Do you still encounter this issue? I've been using connection reuse on quite a few different things now and havent encountered any errors. If you still have the problem, could you post a code snippet or test that reproduces it? |
@whyrusleeping I've been too swamped to get back to testing it but at this point, with your successful reuse, I'd assume it's my error somewhere. I'll let you know if I come up with a reproducible case :) |
Version information:
go-ipfs version: 0.4.6-dev-
Repo version: 5
System version: amd64/darwin
Golang version: go1.7
Type:
Bug
Priority:
P4
Description:
On @whyrusleeping’s suggestion I’m opening this issue which may involve the go-ipfs node not dealing properly with connection reuse.
The problem manifests as an
X-Stream-Error
response and a trailer with the errorX-Stream-Error: multipart: Part Read: http: invalid Read on closed Body
. The full exchange is shown in the following gist (ascii and hex dump).The exchange is between the swift-ipfs-api and a localhost go-ipfs node.
The standard Cocoa frameworks recommended for URL connections do not allow for setting the http header field
connection: close
(see section on reserved HTTP Headers here) which means they are sent withconnection: keep-alive
. This (probably?) causes the ipfs node to reuse the connection and not always succeeding (sometimes it works, sometimes it partially works and other times it just fails).The issue is whether the ipfs node is/should be able to properly handle connection reuse or whether Cocoa (mac & iOS) API clients need to force a
connection: close
on the headers by using a more low-level approach.let me know if you need any more info.
:) Teo
The text was updated successfully, but these errors were encountered: