go-ipfs version: 0.4.13-3b16b74
Repo version: 6
System version: amd64/linux
Golang version: go1.9.2
Bug
Hey!
I have an issue, I'm not sure it is directly related to go-ipfs though. Anyway, I'm running the Docker image on ipfs.ptrk.io. When I do curl http://ipfs.ptrk.io:5001/api/v0/version it is all good. However when I run curl https://ipfs.ptrk.io/api/v0/version I get the wanted output but curl is still waiting (ie, I don't get the shell back). After about 1min, I get curl: (56) Unexpected EOF.
When I try on the browser, I get the result but the page is still loading.
Also, running curl http://ipfs.ptrk.io:5001/api/v0/version --http1.1 works normally. I guess there is some problem with http2 but I'm not sure if the issue is with Traefik or go-ipfs.
Feel free to ask for more information :)
Cheers!
interesting... this feels like a bug.
For information I also got this error on go-ipfs version: 0.4.15 and I also use Traefik
I am also getting this error, using Traefik.
@Pneumaticat What is your setup? Do you have a gateway running on a server with nginx? How are you reproducing the issue?
Initially, I had Traefik reverse-proxying port 5001 to IPFS daemon's port 5001, doing TLS termination as well. This created the situation where HTTP 1.1 worked fine, but HTTP 2 hung for approximately 3 minutes.
I then switched to a nginx reverse proxy of 5001 (again doing TLS termination), which seems to work fine with both HTTP 1 and 2. This might be a traefik bug, then.
Or a go http bug. We've run across several, unfortunately.
Does anyone has some workaround for this one ? :(
I solved this issue by using ngingx reverse proxy instead of traefik and now this is working so I don't think it is linked to goipfs but maybe an issue with traefik.
Most helpful comment
Initially, I had Traefik reverse-proxying port 5001 to IPFS daemon's port 5001, doing TLS termination as well. This created the situation where HTTP 1.1 worked fine, but HTTP 2 hung for approximately 3 minutes.
I then switched to a nginx reverse proxy of 5001 (again doing TLS termination), which seems to work fine with both HTTP 1 and 2. This might be a traefik bug, then.