Skip to content

misc/wasm: On WSL, test code works when served over HTTPS / HTTP/2; not with HTTP 1.1 #37095

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Gregory-Ledray opened this issue Feb 6, 2020 · 2 comments
Labels
arch-wasm WebAssembly issues FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@Gregory-Ledray
Copy link

Gregory-Ledray commented Feb 6, 2020

Yes, I'm aware the name of this Issue seems impossible. But it's true.

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

$ go version
go version go1.13.7 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="amd64"
GOBIN=""
GOCACHE="/home/greg/.cache/go-build"
GOENV="/home/greg/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/greg/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/mnt/c/Users/gledr/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/buggyHTTP/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build313322648=/tmp/go-build -gno-record-gcc-swit
ches"

What did you do?

package main

import (
	"github.com/rs/cors"
	"net/http"
	"os"
	"runtime"
	"time"
)

func main() {
	mux := http.NewServeMux()
	fs := http.FileServer(http.Dir("./serveThis"))
	mux.Handle("/", fs)
	handler := cors.New(cors.Options{
		AllowCredentials: true,
		AllowedMethods:   []string{"GET", "POST", "PUT"},
		AllowedOrigins:   []string{"https://localhost:*", "http://localhost:*", "*"},
		AllowedHeaders:   []string{"Accept", "Accept-Language", "Accept-Encoding", "Content-Type", "Content-Length", "Authorization"},
		MaxAge:           120,
	}).Handler(mux)
	server := &http.Server{
		Addr:           ":5100",
		Handler:        handler,
		IdleTimeout:    60 * time.Second,
		ReadTimeout:    60 * time.Second,
		WriteTimeout:   60 * time.Second,
		MaxHeaderBytes: 1 << 20,
	}

	var err error

	// working (the errors are expected - it succeeded because it says in the browser:
	// --- FAIL: TestAlwaysFail (0.00s)
	// main_integration_test.go:25: always fail
	tlsPath := ""
	if runtime.GOOS == "windows" {
		tlsPath = os.Getenv("TLSPATH") + "\\\\"
	} else {
		tlsPath = os.Getenv("TLSPATH") + string(os.PathSeparator)
	}
	err = server.ListenAndServeTLS(tlsPath+"server.crt", tlsPath+"server.key")

	// TODO not working
	// error in Firefox: DOMException: "The operation was aborted. "
	// error in Chrome: Failed to load resource: the server responded with a status of 404 (Not Found)
	// next error in Chrome: Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH
	// next error in Chrome: TypeError: Could not download wasm module
	// err = server.ListenAndServe()

	if err != nil {
		panic(err)
	}
}

What did you expect to see?

Explained in the comments, but the file in the repo is a test file compiled to WASM and being loaded into the browser to help me run the tests. I expect it to run the tests, which it does do when using TLS.

What did you see instead?

When using HTTP 1.1 (aka ListenAndServe, not ListenAndServeTLS) the WASM file fails to load.

Reproduction Info

You can use the repo here with these instructions:

git clone https://gitlab.com/polyapp-open-source/buggyHTTP
cd buggyHTTP
go build
./buggyHTTP

Then open a browser to https://localhost:5100 and see that it works (this is the https version, after all).

Go back and switch which lines are being used to serve the files. Rebuild and serve.

Notes

@odeke-em odeke-em changed the title WASM test code works when served over HTTPS / HTTP/2; not with HTTP 1.1 misc/wasm: test code works when served over HTTPS / HTTP/2; not with HTTP 1.1 Feb 7, 2020
@odeke-em odeke-em added arch-wasm WebAssembly issues NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 7, 2020
@Gregory-Ledray Gregory-Ledray changed the title misc/wasm: test code works when served over HTTPS / HTTP/2; not with HTTP 1.1 misc/wasm: On WSL, test code works when served over HTTPS / HTTP/2; not with HTTP 1.1 Feb 7, 2020
@agnivade
Copy link
Contributor

I am unable to reproduce this on Linux. Your included wasm_exec.js was outdated for 1.14, so I used the wasm_exec.html and wasm_exec.js from the 1.14 toolchain and just compiled a simple Hello world binary. Serving those with the main.go in ListenAndServe works fine for me.

I see that you mention that it happens in WSL and not in Windows. However, the wasm file should be the same throughout. Is the contents of the wasm file different under different platforms? Does the same binary (built on WSL) work when you run the HTTP server in different platforms?

@agnivade agnivade added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jul 12, 2020
@gopherbot
Copy link
Contributor

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Aug 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly issues FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

4 participants