ALPN problem: IIS aborts the TLS handshake for HTTP 1.0 requests #12259
I did this
Connect to a Microsoft IIS 10 server with HTTP 1.0:
IIS aborts the TLS handshake with a TCP reset (RST) after the "client hello" message.
This is a regression, it works with curl 7.87.0 and earlier.
The root cause of the problem is the ALPN protocol that curl sends to the server. curl 7.88.0 has started to send "http/1.0" (commit df856cb, discussion #10183). Earlier curl versions use the ALPN protocol "http/1.1", even for HTTP 1.0 requests.
My guess is that the IIS server does not know the ALPN protocol "http/1.0". The original ALPN specification does not contain "http/1.0", but it contains "http/1.1".
Side note: Firefox also uses the ALPN protocol "http/1.1" even if the setting "network.http.version" is set to "1.0".
This hack fixes the problem:
Workaround: Use the parameter
I expected the following
curl 8.5.0-DEV (x86_64-pc-linux-gnu) libcurl/8.5.0-DEV OpenSSL/3.0.9 nghttp2/1.52.0
Fedora Linux 38
The text was updated successfully, but these errors were encountered:
Is the ALPN protocol "http/1.0" mentioned in any RFC? I don't understand why it's in the IANA registry.
It's a backwards compatibility issue. At the time ALPN was invented, the only known ALPN protocols were "http/1.1", "spdy/1", "spdy/2" and "spdy/3", so there was no other choice but to also use "http/1.1" for HTTP 1.0.
So in practice the ALPN protocol "http/1.1" probably means "HTTP 1.x".
That's not how it works. ALPN is an RFC and a mechanism to negotiate the underlying protocol. any protocol. They are negotiated using "Protocol IDs". The IANA registry lists all those valid and official protocol ids.
Possibly, for some legacy servers sure. The question is still what curl should do about it. Willingly just send the wrong Id just because there might be some wrong servers out there or simply let users use
After all, going HTTP/1.0 is a very special situation to begin with.
A HTTP server supporting HTTP/1.1 and HTTP/1.0 will always have to detect the version in play from the request parsed. It is a property of the request, not the connection while ALPN is a property of the connection.
One could say that after seeing ALPN
That IIS is rejecting
I think for