Replies: 1 comment 11 replies
-
|
A HTTP/2 server sending a GOAWAY indicates up to which stream id (inclusive) it will continue to process before closing the connection. All ongoing streams with a higher id will not. The retry behaviour in the |
Beta Was this translation helpful? Give feedback.
11 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I am using curl 8.15.0 and multi interface and everything works as expected, however at some point I see this error Connection died, tried 5 times before giving up
I would expect that should never happen, the current config I have has:
Multi (connection pool)
CURLMOPT_MAX_TOTAL_CONNECTIONS=1024
CURLMOPT_MAX_HOST_CONNECTIONS=64
CURLMOPT_MAXCONNECTS=256
CURLMOPT_MAX_CONCURRENT_STREAMS=100
CURLMOPT_PIPELINING=HTTP1|MULTIPLEX # enable HTTP/1.1 pipelining and HTTP/2 multiplexing
Easy (per transfer)
CURLOPT_DNS_CACHE_TIMEOUT=60 # seconds
CURLOPT_TCP_KEEPALIVE=1 # on
CURLOPT_TCP_KEEPIDLE=10 # seconds
CURLOPT_TCP_KEEPINTVL=5 # seconds
CURLOPT_TCP_KEEPCNT=3 # probes
CURLOPT_MAXAGE_CONN=118 # seconds
CURLOPT_CONNECTTIMEOUT=5 # seconds
CURLOPT_TCP_NODELAY=1 # on
CURLOPT_PIPEWAIT=1 # on
CURLOPT_FOLLOWLOCATION=1 # on
CURLOPT_LOW_SPEED_TIME=20 # seconds
CURLOPT_LOW_SPEED_LIMIT=100 # bytes/sec
Debug logs from the issue:
debug..txt
What i notice from this log is that we receive the GOAWAY that has last_stream=3693
and all the failing requests I see they have higher stream_id
I would expect libcurl to try on a new connection but seems like it doesn't?
Beta Was this translation helpful? Give feedback.
All reactions