http3: Can't fallback to http2 on Windows (CURLE_BAD_FUNCTION_ARGUMENT) #11832
Comments
bagder
added
HTTP/2
connecting & proxies
HTTP/3
That one is unexpected and suspicious! |
|
Does 8.4.0 work any better? |
|
|
|
- when a connect immediately goes into DRAINING state, do not attempt retries in the QUIC connection filter. Instead, return CURLE_WEIRD_SERVER_REPLY - When eyeballing, interpret CURLE_WEIRD_SERVER_REPLY as an inconclusive answer. When all addresses have been attempted, rewind the address list once on an inconclusive answer. - refs curl#11832 where connects were retried indefinitely until the overall timeout fired
- when a connect immediately goes into DRAINING state, do not attempt retries in the QUIC connection filter. Instead, return CURLE_WEIRD_SERVER_REPLY - When eyeballing, interpret CURLE_WEIRD_SERVER_REPLY as an inconclusive answer. When all addresses have been attempted, rewind the address list once on an inconclusive answer. - refs curl#11832 where connects were retried indefinitely until the overall timeout fired
|
I made #12401 with the hope that something like that should be able to help us pinpoint this problem better. |
|
- when a connect immediately goes into DRAINING state, do not attempt retries in the QUIC connection filter. Instead, return CURLE_WEIRD_SERVER_REPLY - When eyeballing, interpret CURLE_WEIRD_SERVER_REPLY as an inconclusive answer. When all addresses have been attempted, rewind the address list once on an inconclusive answer. - refs #11832 where connects were retried indefinitely until the overall timeout fired Closes #12400
|
I don't have a Windows build environment... |
|
curl for windows 8.4.0 returns CURLE_BAD_FUNCTION_ARGUMENT (43) and the daily build curl-8.5.0-DEV_20231129-win64-mingw returns CURLE_WEIRD_SERVER_REPLY (8) 8.4.0: 8.5.0-DEV_20231129: OT but isn't cipher selection going to be the same every time, is it necessary to show it for every connect now? |
|
@jay the eyeballing in QUIC always involves a new TLS instance for every connection. That is why it is showing the messages. I doubt we can avoid that. We could suppress the messages, I assume... |
Yeah I see the same. I notice those curl commits don't have any bearing on QUIC and that otherwise the manifest of the build is the same (same dependencies). Maybe this is a curl-for-win issue? It looks like curl-for-win switched to cmake and then there was no longer bad argument but somehow it came back on or before 20231129. |
|
Is this still happening? |
AFAICT no. I tested curl-8.6.1-DEV_20240212-win64-mingw (backup link for posterity) and I see a bunch of "weird server reply" to all the QUIC but after that curl falls back to HTTP/2. It would be nice if someone could confirm. |
|
Presumed fixed or at least changed behavior. |
I did this
crypto.cloudflare.com does not support h3, but curl does not fallback to h2.
I expected the following
Test on android:
curl/libcurl version
curl 8.2.1 (x86_64-w64-mingw32) libcurl/8.2.1 OpenSSL/3.1.2 (Schannel) zlib/1.3 brotli/1.1.0 zstd/1.5.5 WinIDN libssh2/1.11.0 nghttp2/1.56.0 ngtcp2/0.19.1 nghttp3/0.15.0
Release-Date: 2023-07-26
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI threadsafe UnixSockets zstd
operating system
windows
The text was updated successfully, but these errors were encountered: