This adds a wazero implementation in order to make the project CGO-free. For example, there's no need to load native libraries (as currently exists with wasmer). To achieve this, I added a go.mod file for wasmer.

Fixes https://github.com/mosn/proxy-wasm-go-host/issues/15

Per #10 the current code doesn't properly implement v0.1.0, and worse that version isn't really used or maintained anymore. I suggest focusing effort on maintained ABI. Notably this should also drop "wasi_unstable" for "wasi_snapshot_preview1" as that's what's in use by current compilers.

Until this is dropped implementing another host impl is too much low value work, as it is porting for unused and unmaintable ABI.

@taoyuanyuan @antJack FYI I'm pausing efforts until this is done as I am way over budget already and there's no value proceeding if we have to support an incorrect implementation of an unused ABI version.

Since I was here, I figured I'd bump the libraries. Nice that the example works!

## Build it
$ (cd example; go build .)

## Ensure the linked libraries are there
$ otool -L example/example
example/example:
	@rpath/libwasmer.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

$ du -k example/example 
10512	example/example

$ du -k vendor/github.com/wasmerio/wasmer-go/wasmer/packaged/lib/darwin-amd64/libwasmer.dylib 
10404	vendor/github.com/wasmerio/wasmer-go/wasmer/packaged/lib/darwin-amd64/libwasmer.dylib

## try it
$ (cd example; ./example)
receive request /
print header from server host, User-Agent -> [curl/7.79.1]
print header from server host, Accept -> [*/*]
[http_wasm_example.cc:33]::onRequestHeaders() print from wasm, onRequestHeaders, context id: 2
[http_wasm_example.cc:38]::onRequestHeaders() print from wasm, Accept -> */*
[http_wasm_example.cc:38]::onRequestHeaders() print from wasm, User-Agent -> curl/7.79.1

PS if the intention is to keep floor go 1.14, definitely wazero won't work as we follow Go's support policy, and even if we didn't 1.14 is too far back.

This migrates in functionality in mosn/mosn that drifted due to copy/paste. The result is better quality here instead of having the wasmer tests delayed until integrated into mosn.

This also hides the implementation of host functions, as they should never be invoked directly. Host functions should only be invoked by the wasm runtime, ex wasmer or wazero. In doing this, I also started contextualizing them, even though wasmer doesn't support that invocation style. This will help in trace logging in wazero.

When trying wazero I came to the incorrect conclusion that things work, because nothing was tested and errors were ignored.

This adds tests. It also fixes a go convention problem where the name wasmer is repeated both in package and function names.

Here are the initial benchmark results on my laptop:

BenchmarkStartInstanceV1
BenchmarkStartInstanceV1-16    	      25	  48623804 ns/op
BenchmarkCallGuestV1
BenchmarkCallGuestV1-16        	   81004	     14533 ns/op

I am trying to use this module in my proxy code, while I am running go get I get the following error - #go get mosn.io/proxy-wasm-go-host/proxywasm/common
#go get: module mosn.io/[email protected] found (v0.1.0), but does not contain package mosn.io/proxy-wasm-go-host/proxywasm/common

I am trying to add a header element to the request OnHttpRequestHeaders. It's not working or an error. Sample call - proxywasm.AddHttpRequestHeader("Debug", "1"), After this call context return back to the caller no instruction are executed.

This updates wazero to 1.0.0-pre.4.

Notably, v1.0.0-pre.4:

• improves module initialization speed
• supports listeners in the compiler engine
• supports WASI fd_pread, fd_readdir and path_filestat_get

This makes wasmer use the same wasmer build flag as mosn does, to prevent it from being built-in by default.

This enables wazero by default, using a non-tagged version until the end of the month when using wasi_unstable is configurable in the next version.

BenchmarkStartABIContextV1_wazero
BenchmarkStartABIContextV1_wazero-16     	      73	  13924962 ns/op
BenchmarkAddRequestHeaderV1_wazero
BenchmarkAddRequestHeaderV1_wazero-16    	  145736	      7260 ns/op
BenchmarkStartABIContextV2_wazero
BenchmarkStartABIContextV2_wazero-16     	      88	  13720664 ns/op
BenchmarkAddRequestHeaderV2_wazero
BenchmarkAddRequestHeaderV2_wazero-16    	  164587	      7250 ns/op
BenchmarkStartABIContextV1_wasmer
BenchmarkStartABIContextV1_wasmer-16     	     225	   8061989 ns/op
BenchmarkAddRequestHeaderV1_wasmer
BenchmarkAddRequestHeaderV1_wasmer-16    	   75734	     15168 ns/op
BenchmarkStartABIContextV2_wasmer
BenchmarkStartABIContextV2_wasmer-16     	      79	  13223690 ns/op
BenchmarkAddRequestHeaderV2_wasmer
BenchmarkAddRequestHeaderV2_wasmer-16    	   77937	     16036 ns/op

Fixes #15

Currently, the example points users the wrong way as no SDK is maintaining 0.1 anymore. Is it ok if I change it to something maintained? Ex tinygo with 0.2?

cc @taoyuanyuan @antJack

Ex. here's the current plugin used in tests ported to a currently maintained SDK in go

package main

import (
	"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm"
	"github.com/tetratelabs/proxy-wasm-go-sdk/proxywasm/types"
)

// build main with `tinygo build -o main.wasm -scheduler=none -target=wasi ./main.go`
func main() {
	proxywasm.SetVMContext(&vmContext{})
}

type vmContext struct {
	// Embed the default VM context here,
	// so that we don't need to reimplement all the methods.
	types.DefaultVMContext
}

// NewPluginContext overrides types.DefaultVMContext.
func (*vmContext) NewPluginContext(contextID uint32) types.PluginContext {
	return &pluginContext{}
}

type pluginContext struct {
	// Embed the default plugin context here,
	// so that we don't need to reimplement all the methods.
	types.DefaultPluginContext
}

// NewHttpContext overrides types.DefaultPluginContext.
func (*pluginContext) NewHttpContext(contextID uint32) types.HttpContext {
	return &httpHeaders{contextID: contextID}
}

type httpHeaders struct {
	// Embed the default http context here,
	// so that we don't need to reimplement all the methods.
	types.DefaultHttpContext
	contextID uint32
}

// OnHttpRequestHeaders overrides types.DefaultHttpContext.
func (ctx *httpHeaders) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
	proxywasm.LogDebugf("print from wasm, onRequestHeaders, context id: %d", ctx.contextID)

	hs, err := proxywasm.GetHttpRequestHeaders()
	if err != nil {
		proxywasm.LogCriticalf("failed to get request headers: %v", err)
	}

	for _, h := range hs {
		proxywasm.LogInfof("print from wasm, %s -> %s", h[0], h[1])
	}
	return types.ActionContinue
}

for function call, []byte is more generic than string

reference: https://github.com/tetratelabs/proxy-wasm-go-sdk/blob/98ee1a9ebc5e1d32a8c044611acab87b4340393f/proxywasm/hostcall.go#L85

This updates wazero to 1.0.0-pre.6.

Notably, v1.0.0-pre.6:

• improves module compilation and initialization performance

The following features aren't used here, but could be in the future.

• adds writefs.NewDirFS which lets you add new files.
  • path_open O_CREAT flags, path_remove_directory path_rename path_unlink_file
• adds NewFilesystemLoggingListenerFactory with dramatically improved logging.

This also includes changes described in 1.0.0-pre.5. Notably, context param was removed from memory functions as it was never used due to the scope being very narrow, and adds overhead to propagate.

action

cd example and replace the wasm file to new file which handles HTTP headers like this. Then go run . run the example.

expected behaviour

If the header hit, Action::Pause will be returned from wasm side. ActionPause will be returned by the function ProxyOnRequestHeaders.

actual behaviour

Regardless of whether the expected header appears. ActionContinue will be returned by the function ProxyOnRequestHeaders

about the code

I noticed that the action ProxyOnRequestHeaders returned is actually from CallWasmFunction, and res is ignored.

Whether action should be ignored, the value of res should be converted into action format and returned. And what is a.Imports.Wait() actually do, is there any example for it?

Hello!

It was pointed out to me (see: https://github.com/proxy-wasm/proxy-wasm-rust-sdk/issues/104) that Proxy-Wasm Go Host doesn't expose all Proxy-Wasm ABI v0.1.0 hostcalls.

Looking at the code, neither imports nor exports match the specification, e.g. host exports proxy_dispatch_http_call and imports proxy_on_plugin_start, but those don't exists in any of the existing versions (ABI v0.1.0, v0.2.0 or v0.2.1).

I believe that the source of the confusion might be the work-in-progress specification for vNEXT in proxy-wasm/spec, although even that doesn't define proxy_on_plugin_start, so it's unclear to me what's the source for your v1 and v2.

Note that there is no documention for either ABI v0.1.0, v0.2.0 or v0.2.1, so the code in Envoy and Proxy-Wasm SDKs is effectively the specification for those versions.