Open WebFreak001 opened 4 years ago
I'm having a similar problem, and have isolated to what I think is the cause: I'm using the defaultSettings
for HTTPClientSettings
on my requestHTTP
calls. If there is no activity on a connection for a while and then I attempt to do another call it fails. I suspect the defaultKeepAliveTimeout is way too long and connections are expired by the server. I have now started using custom settings with a much lower timeout to see if this fixes the issue.
good idea! I didn't think about the OpenSSL error message too hard yet but a timeout might be the reason this happens here.
The server tries to Connection: Upgrade, close
with Upgrade: h2
. In vibe.d it looks like it only cancels if it is == "close"
so I think this might be the whole reason: https://github.com/vibe-d/vibe.d/blob/4076c01d438f39c358f976af69241243177c0d14/http/vibe/http/client.d#L1065
It does close it earlier for being not keep-alive too which is probably breaking here: https://github.com/vibe-d/vibe.d/blob/4076c01d438f39c358f976af69241243177c0d14/http/vibe/http/client.d#L758
The connection header may be a comma separated list of tokens which contains header names or keep-alive or close. I found if there is both keep-alive and close it is not defined what to choose from, but I think close is the better use there. It also says a system receiving HTTP/1.0 or lower messages must ignore all the headers specified in the Connection header, but it doesn't say what to do with HTTP/1.1
Still I think iterating over the Connection header and checking for a close
token would be the best way to go
Unfortunately setting keepAliveTimeout in HTTPClientSettings did not help. I'm starting to wonder whether the problem is that the check for the underlying TCP connection being still valid in this line: https://github.com/vibe-d/vibe.d/blob/4076c01d438f39c358f976af69241243177c0d14/http/vibe/http/client.d#L638 is somehow passing, despite the fact that it has been closed. I'm going to check whether this is limited to TLS connections or also manifests on simple HTTP connections.
So I've been able to confirm with Wireshark that vibe.d http client is attempting to reuse the connection from the connection pool, despite the fact that the server has closed the keep-alive connection. It then gets a TCP RST back (unsurprisingly) which causes the openssl error message seen above. Now need to understand why the check referred to in my comment above (which seems to be an attempt to prevent re-use of a closed connection) is not preventing this.
Ok. Some further investigation has revealed that the issue I was seeing has been resolved in vibe.d master (I was depending on vibe 0.8.6). The check I was referring to above is working, but IMHO is in the wrong place - hence the existence of the slightly kludgy doRequestWithRetry
method. It doesn't appear that the keepAliveTimeout in HTTPClientSettings is honoured correctly. Anyway it works for me now.
well I am using master and this problem only appeared here (though I didn't test this particular app with previous versions yet)
I'm currently experiencing issues trying to do http client calls using vibe.d (current mongo-index branch on #2433, basically ~master) with vibe-core 1.9.1 and openssl 1.1.6+1.0.1g sometimes causes this issue when trying to send a http request:
the calling code is basically
and it happens very randomly (around 5% of the tries) but this doesn't seem to be reproducible in isolation. Also this HTTP request is being performed while there is another HTTP long polling call open and waiting for data. (using tg-d package to be precise)
Do you have any suggestion what could cause this?
If it's something with long polling you want to test, I made a site to test long polling: https://longpolltest.webfreak.org/?t=2 but I couldn't reproduce it in isolation with it yet