net/http: http client regression building with js/wasm and running on Chrome: `net::ERR_H2_OR_QUIC_REQUIRED`

[jnowls]

What version of Go are you using (go version)?

$ go version
go version go1.21.0 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=''
GOARCH='wasm'
GOBIN=''
GOCACHE='/home/h/.cache/go-build'
GOENV='/home/h/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/h/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='js'
GOPATH='/home/h/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.0'
GCCGO='gccgo'
GOWASM=''
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='0'
GOMOD='/home/h/code/pk/axesfull/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build4139731908=/tmp/go-build -gno-record-gcc-switches'
uname -sr: Linux 6.4.8-arch1-1
LSB Version:	n/a
Distributor ID:	Arch
Description:	Arch Linux
Release:	rolling
Codename:	n/a
/usr/lib/libc.so.6: GNU C Library (GNU libc) stable release version 2.38.

What did you do?

NOTE: I only get these errors in Chromium based browsers, not in Firefox.

I have this following function:

type Account struct {
	ID string `json:"id"`
}

func TestPersist(t *testing.T) {
	fmt.Printf("runtime.Version(): %v\n", runtime.Version())
	acc := Account{"5e7fd575-b5f5-4d7e-8fa7-70b5fef7662f"}
	buf, _ := json.Marshal(acc)
	r := bytes.NewBuffer(buf)
	req, err := http.NewRequest("POST", "https://nk.axesfull.dev/v2/account/authenticate/device", r)
	if err != nil {
		t.Fatalf("could not create request: %v", err)
	}
	_, err = http.DefaultClient.Do(req)
	if err != nil {
		t.Fatalf("could not authenticate account: %v", err)
	}
}

compiled with:
GOOS=js GOARCH=wasm go test -c -o test.wasm -run TestPersist

I ran this with the default wasm_exec.html thats provided in $GOROOT/misc/wasm with just adding test.v to argv:.

		async function run() {
			console.clear();
			await go.run(inst);
			go.arvc = ["js", "-test.v"]
			inst = await WebAssembly.instantiate(mod, go.importObject); // reset instance
		}

This works with go1.20, but not with go1.21.

Reproducible example available at https://github.com/jnowls/wasm-http-chrome - just run ./run.sh

What did you expect to see?

The browser successfully complete the request (as seen in Firefox and older versions of chrome)

What did you see instead?

Firefox go1.21 and go1.20:

Chrome go1.21 and go1.20:

[mknyszek]

CC @neild

[samstride]

Hi,

Running into this issue with go v1.21.0.

go version go1.21.0 linux/amd64

No issues on go v1.20.7

My understanding is that this has something to do with HTTP 1 vs 2.

In my case, since I am on local machine, the server runs on localhost (http1) and hence run into this issue. If the connection is over HTTP2 (PROD server), I do not get this error.

Will be nice to see feature detection added as described here?

https://developer.chrome.com/articles/fetch-streaming-requests/#doesnt-work-on-http1x

Thanks.

[jnowls]

Hi,

Running into this issue with go v1.21.0.

go version go1.21.0 linux/amd64

No issues on go v1.20.7

My understanding is that this has something to do with the connection not being secure.

In my case, since I am on local machine, the server runs on localhost and hence run into this issue. If the connection is secure (PROD server), I do not get this error.

Will be nice to see feature detection added as described here?

https://developer.chrome.com/articles/fetch-streaming-requests/#doesnt-work-on-http1x

Thanks.

Just to clarify, based on that article and my own testing, it's not an issue with HTTP or HTTPS, but more with HTTP 1, regardless of whether SSL/TLS is there or not.

[haruyama480]

I reproduced the same error as reported.

And, I found that the following merge was the trigger.
https://go-review.googlesource.com/c/go/+/458395

The following line implements that request body is streamed if the browser supports streaming, regardless fetch() use http/1 or 2.
https://go-review.googlesource.com/c/go/+/458395/10/src/net/http/roundtrip_js.go#135

The error net::ERR_H2_OR_QUIC_REQUIRED literally indicates that the streaming is not supported by http/1.
If roundtrip_js.go doesn't need to support http/2, 458395 should be reverted. Otherwise, it seems to need a flag of whether client uses http1 or 2.

supportsPostRequestStreams determines whether the browser can stream request body. Firefox doesn't support it, but Chrome does support it. So, this error doesn't happen on Firefox. I guess that all POST requests from almost Chrome via http/1 fail until fix.

[haruyama480]

I wrote minimum example. https://github.com/haruyama480/go1210-request-streaming-failed

[samstride]

@jnowls. Correct. Sorry, should have worded it better.

Just to clarify, based on that article and my own testing, it's not an issue with HTTP or HTTPS, but more with HTTP 1, regardless of whether SSL/TLS is there or not.

[haruyama480]

Let me summarize this issue.

Issue

• Excuting wasm binary built by go1.21.0 which does POST request to 'http://..' on in Chromium-based browser caused the error net::ERR_H2_OR_QUIC_REQUIRED
• this issue doesn't reproduce for go1.20, Firefox, or GET request.

Cause

• This issue is triggered by the commit 458395. The commit intended enable request streaming if available in client. However, according to this article, request streaming isn't supported by http/2, and doesn't work if server or proxy doesn't support it.
• Although Chrome doesn't implement http/2 requests for no TLS, Chrome does streaming requests to 'http://..' nevertheless via http/1, and consequently failed even sending requests.

How to solve

I think there are following solutions.
a. implement an option so that clients can control the use of stream
b. greedy use streaming for https request and disable it for http request
c. both
d. or just revert it, and wait utill enough discussion

a and b have limitations: a forces developers to use options properly and b ignores server or proxy supportings. but, a would be easy way, if you implement it via global vars, such as omitBundledHTTP2 though it makes developer use only one of http or https on one wasm binary.

Yes, I'm not very familiar with the go repository, so could I ask how to fix to Go team or code owner? @johanbrandhorst

If there is chance, I would like to contribute to fix it. :)

[johanbrandhorst]

CC @hawkinsw. Please feel free to open a CL with a fix, sorry for the inconvenience!

[hhhapz]

Thanks for the offer of contributing the fix @haruyama480 :)

I don't see any quick and easy way to determine whether or not the browser will complete a HTTP request with H2 or H1 before it happens :(. Just disabling request streaming for HTTP also probably isn't a proper fix since POST requests with HTTPS+H1 (what OP describes) also fail.

If we do end up going with implementing it such that clients select whether to use the streaming API, that should probably not be done with a global variable, it will only make things more complicated to deal with, though I'm not sure what the best alternative to give the client the control is.

I personally think request streaming should be reverted for now, and revisited at a later point where the streaming API provides proper mechanisms to fallback in case of no support from the server.