HTTP/2 requests responding with GOAWAY error HTTP_1_1_REQUIRED are retried with HTTP/2

[drmathias]

I did this

I'm running a reverse proxy server that is configured to advertise both h2 and http/1.1 in ALPN - some endpoints support HTTP/2 and others do not. Those that do not support HTTP/2 send GOAWAY with HTTP_1_1_REQUIRED as the error code.

When sending a request using cURL, on retry curl advertises h2 in ALPN, causing the server to renegotiate HTTP/2.

=> Send header, 80 bytes (0x50)
0000: GET / HTTP/2
000e: Host: pwrti8go.jvln.test
0028: User-Agent: curl/8.22.0
0041: Accept: /
004e:

• Request completely sent off
  <= Recv SSL data, 5 bytes (0x5)
  0000: ....!
  <= Recv SSL data, 5 bytes (0x5)
  0000: ....)
• received GOAWAY, error=13, last_stream=0
• HTTP/2 stream 1 refused by server, try again on a new connection
  => Send SSL data, 5 bytes (0x5)
  0000: ....!
• REFUSED_STREAM, retrying a fresh connect
• Connection died, retrying a fresh connect (retry count: 4)
• shutting down connection #...
• Issue another request to this URL: 'https://pwrti8go.jvln.test/'
• Hostname pwrti8go.jvln.test was found in DNS cache
• Host pwrti8go.jvln.test:443 was resolved.
• IPv6: (none)
• IPv4: 127.0.0.1
• Trying 127.0.0.1:443...
• SSL reusing session with ALPN '-'
• SSL verify result: 0
• ALPN: curl offers h2,http/1.

I expected the following

On retry, only http/1.1 should be advertised by curl

curl/libcurl version

curl 8.22.0 (x86_64-apple-darwin25.2.0) libcurl/8.22.0 OpenSSL/3.6.4 zlib/1.2.12 brotli/1.2.0 zstd/1.5.7 AppleIDN libpsl/0.23.3 libssh2/1.11.1 nghttp2/1.70.0 ngtcp2/1.25.0 nghttp3/1.18.0 mit-krb5/1.7-prerelease OpenLDAP/2.4.28/Apple
Release-Date: 2026-09-02

operating system

Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:34 PST 2025; root:xnu-12377.61.12~1/RELEASE_X86_64 x86_64

[jay]

Confirmed using master 8.22.1-DEV, 8.4.0 and 8.5.0. It looks like this is the code that makes it retry on HTTP_1_1_REQUIRED:

curl/lib/multi.c

Lines 2063 to 2092 in 0134682

	#ifndef CURL_DISABLE_HTTP
	else if((result == CURLE_HTTP2_STREAM) &&
	Curl_h2_http_1_1_error(data)) {
	CURLcode ret = Curl_retry_request(data, &newurl);
	if(!ret) {
	infof(data, "Downgrades to HTTP/1.1");
	streamclose(data->conn);
	data->state.http_neg.wanted = CURL_HTTP_V1x;
	data->state.http_neg.allowed = CURL_HTTP_V1x;
	/* clear the error message bit too as we ignore the one we got */
	data->state.errorbuf = FALSE;
	if(!newurl)
	/* typically for HTTP_1_1_REQUIRED error on first flight */
	newurl = Curl_bufref_dup(&data->state.url);
	if(!newurl) {
	result = CURLE_OUT_OF_MEMORY;
	}
	else {
	/* if we are to retry, set the result to OK and consider the request
	as done */
	retry = TRUE;
	result = CURLE_OK;
	data->req.done = TRUE;
	}
	}
	else
	result = ret;
	}
	#endif

ALPN selection:

curl/lib/vtls/vtls.c

Lines 98 to 122 in 0134682

	static const struct alpn_spec *alpn_get_spec(http_majors wanted,
	http_majors preferred,
	bool only_http_10,
	bool use_alpn)
	{
	if(!use_alpn)
	return NULL;
	/* If HTTP/1.0 is the wanted protocol then use ALPN http/1.0 and http/1.1.
	This is for compatibility reasons since some HTTP/1.0 servers with old
	ALPN implementations understand ALPN http/1.1 but not http/1.0. */
	if(only_http_10 && (wanted & CURL_HTTP_V1x))
	return &ALPN_SPEC_H10_H11;
	#ifdef USE_HTTP2
	if(wanted & CURL_HTTP_V2x) {
	if(wanted & CURL_HTTP_V1x)
	return (preferred == CURL_HTTP_V1x) ?
	&ALPN_SPEC_H11_H2 : &ALPN_SPEC_H2_H11;
	return &ALPN_SPEC_H2;
	}
	#else
	(void)wanted;
	(void)preferred;
	#endif
	return &ALPN_SPEC_H11;
	}

I put some printfs there and wanted on all tries contains CURL_HTTP_V2x and CURL_HTTP_V1x, and preferred is 0.

[jay]

At least in my case curl CURLE_RECV_ERROR causes the retry, so it doesn't interpret it as a downgrade. This may have something to do with the way I'm testing, I'm using a python server to serve the http1.1 required

    h2.close_connection(
        error_code=ErrorCodes.HTTP_1_1_REQUIRED,
        last_stream_id=0,
        additional_data=b"HTTP/1.1 required",
    )

* received GOAWAY, error=13, last_stream=0
* readwrite_data() -> 56
* Curl_readwrite() -> 56
* REFUSED_STREAM, retrying a fresh connect
* Connection died, tried 5 times before giving up

curl/lib/multi.c

Lines 2045 to 2092 in 0134682

	if(data->req.done || (result == CURLE_RECV_ERROR)) {
	/* If CURLE_RECV_ERROR happens early enough, we assume it was a race
	* condition and the server closed the reused connection exactly when we
	* wanted to use it, so figure out if that is indeed the case.
	*/
	CURLcode ret = Curl_retry_request(data, &newurl);
	if(!ret)
	retry = !!newurl;
	else if(!result)
	result = ret;
	if(retry) {
	/* if we are to retry, set the result to OK and consider the
	request as done */
	result = CURLE_OK;
	data->req.done = TRUE;
	}
	}
	#ifndef CURL_DISABLE_HTTP
	else if((result == CURLE_HTTP2_STREAM) &&
	Curl_h2_http_1_1_error(data)) {
	CURLcode ret = Curl_retry_request(data, &newurl);
	if(!ret) {
	infof(data, "Downgrades to HTTP/1.1");
	streamclose(data->conn);
	data->state.http_neg.wanted = CURL_HTTP_V1x;
	data->state.http_neg.allowed = CURL_HTTP_V1x;
	/* clear the error message bit too as we ignore the one we got */
	data->state.errorbuf = FALSE;
	if(!newurl)
	/* typically for HTTP_1_1_REQUIRED error on first flight */
	newurl = Curl_bufref_dup(&data->state.url);
	if(!newurl) {
	result = CURLE_OUT_OF_MEMORY;
	}
	else {
	/* if we are to retry, set the result to OK and consider the request
	as done */
	retry = TRUE;
	result = CURLE_OK;
	data->req.done = TRUE;
	}
	}
	else
	result = ret;
	}
	#endif

[jay]

Well I'm not sure what I did wrong here if anything. Wireshark shows curl responds to the GOAWAY with a GOAWAY of its own and a close notify, then the server sends FIN/ACK. Maybe someone else can test with a proper server.

[icing]

I think we never implemented seeing HTTP_1_1_REQUIRED in a GOAWAY.

[icing]

Could you try #22946 and report if this fixes the problem? Thanks!

[drmathias]

It does appear to fix the problem. Thanks - you're a legend!

• Established connection to mrycwvh24d5gw9zt3m87s8f7z.jvln.test (127.0.0.1 port 443) from 127.0.0.1 port 52713
• using HTTP/2
• [HTTP/2] [1] OPENED stream for https://mrycwvh24d5gw9zt3m87s8f7z.jvln.test/
• [HTTP/2] [1] [:method: GET]
• [HTTP/2] [1] [:scheme: https]
• [HTTP/2] [1] [:authority: mrycwvh24d5gw9zt3m87s8f7z.jvln.test]
• [HTTP/2] [1] [:path: /]
• [HTTP/2] [1] [user-agent: curl/8.22.1-DEV]
• [HTTP/2] [1] [accept: /]

GET / HTTP/2
Host: mrycwvh24d5gw9zt3m87s8f7z.jvln.test
User-Agent: curl/8.22.1-DEV
Accept: /

• Request completely sent off
• received GOAWAY, error=13, last_stream=0
• HTTP/2 stream 1 reset by curl (error 0xd HTTP_1_1_REQUIRED)
• Downgrades to HTTP/1.1
• Empty reply from server
• shutting down connection #0
• Issue another request to this URL: 'https://mrycwvh24d5gw9zt3m87s8f7z.jvln.test/'
• Hostname mrycwvh24d5gw9zt3m87s8f7z.jvln.test was found in DNS cache
• Host mrycwvh24d5gw9zt3m87s8f7z.jvln.test:443 was resolved.
• IPv6: (none)
• IPv4: 127.0.0.1
• Trying 127.0.0.1:443...
• SSL reusing session with ALPN '-'
• SSL verify result: 0
• ALPN: curl offers http/1.1

[icing]

Some background here: HTTP_1_1_REQUIRED is an unusual error code in a GOAWAY. The logic is as follows:

• if the server does not want to talk HTTP/2 at all, it should never negotiate it in the ALPN.
• if the server has a mix of resources, some allow HTTP/2, some do not, it is expected to RST a stream to the latter resources with HTTP_1_1_REQUIRED, leaving the connection alive for the supported resources.

We had tests for this on stream RST, but not for the GOAWAY and I have no test server that can do this. So, if you can in any way influence the developer of your server, tell them that they are in strange country and might encounter other clients that are not expecting this.

[drmathias]

That developer would be myself - it's my first time digging into HTTP/2 framing and this was my solution for handling the scenario where the server has a mix of HTTP/2 and HTTP/1.1 resources. The additional context and explanation is very much appreciated, thank you!