When call ProxyOnRequestHeaders get wrong action

[Taction]

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?

[antJack]

I've noticed that, thanks. That's exactly a question for your rust example. And maybe we should consider the return value of both proxy_on_request_headers and a.Imports.Wait() on ABIContext.ProxyOnRequestHeaders, instead of simply taking the return value of a.Imports.Wait(), and ignoring proxy_on_request_headers.

a.Imports.Wait() is actually for async callout from the wasm module. For example, if you make a HTTP callout in your wasm module, then the go-host should launch the HTTP call, and wait for a response synchronously, and that's the Wait function exactly do. In this case, the ActionContinue from proxy_on_request_headers should be ignored, since you're waiting for the response of the previous HTTP callout to make further decision.

[Taction]

Thanks for your reply. When I stress test the code, whether it uses the original wasm or my own, memory leaks will occur. Do you have any ideas about it?

[antJack]

try pprof, may need to add the following pprof section into mosn config:

[Taction]

Thanks, I'll try it later.

[codefromthecrypt]

@Taction this module is incompatible with any current version of proxy-wasm. The only thing I could get to build is an old version of 0.1.0. I would suggest working with mosn project leads to allow an alternate implementation in mosn. That or we add https://http-wasm.io/http-handler/ and leave proxy-wasm alone. Since you are an end user I think best you help drive action here. cc @taoyuanyuan

package main

import (
	"strconv"

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

// build main like below with proxy-wasm-go-sdk v0.0.14 which works with
// TinyGo 0.19.0 (which works with Go 1.16).
//
//	tinygo build -o main.wasm -scheduler=none -target=wasi -tags 'abi_010' --no-debug ./main.go
//
// Note: Old tooling is needed because mosn.io/proxy-wasm-go-host v2 is
// incompatible with the proxy-wasm specification.
func main() {
	proxywasm.SetNewHttpContext(newHttpContext)
}

type myHttpContext struct {
	// you must embed the default context so that you need not to re-implement all the methods by yourself
	proxywasm.DefaultHttpContext
	contextID uint32
}

func newHttpContext(rootContextID, contextID uint32) proxywasm.HttpContext {
	return &myHttpContext{contextID: contextID}
}

func (ctx *myHttpContext) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action {
	key := "Wasm-Context"
	err := proxywasm.SetHttpRequestHeader(key, strconv.Itoa(int(ctx.contextID)))
	if err != nil {
		proxywasm.LogCritical("failed to set request header: " + key)
	}
	return types.ActionContinue
}