Skip to content
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

Clarify Wasmer support of http_request #40

Open
BenjaminAster opened this issue Jul 12, 2023 · 3 comments
Open

Clarify Wasmer support of http_request #40

BenjaminAster opened this issue Jul 12, 2023 · 3 comments

Comments

@BenjaminAster
Copy link

BenjaminAster commented Jul 12, 2023

The WASIX witx describes the http_request function, but Wasmer (version 4.0.0-beta.3) doesn't seem to recognize it; neither with the default "wasix_32v1" nor with the "wasix_http_client_v1" module name that is referenced in the Wasmer codebase various times. The function also doesn't exist in the WASIX documentation, so is it implemented yet in Wasmer? If not, please prioritize it; making HTTP requests is literally *the* one WASI feature that I would love to see most and it's also precisely the one that doesn't seem to work.

@BenjaminAster BenjaminAster changed the title Confusion about wasmer support of http_request Clarify Wasmer support of http_request Jul 12, 2023
@BenjaminAster
Copy link
Author

Btw, there are currently six functions in the WASIX witx that aren't in the documentation and that Wasmer doesn't recognize:

  • ws_connect
  • http_request
  • http_status
  • epoll_create
  • epoll_ctl
  • epoll_wait

@john-sharratt
Copy link

@BenjaminAster ws_connect, http_request and http_status were deprecated before they were released in place of two altnertives:

  1. reqwest is supported via the standard library and some patched modules, also python and curl work using the libc standard library.
  2. wasix_http_client_v1 is supported under a different namespace. The browser version is already using this when it downloads webc files

@BenjaminAster
Copy link
Author

Thanks for clarifying.
However, I still haven't figured out how to make HTTP requests with WASIX directly. I don't care about Rust, C/C++, or the browser version. I just want to use WASIX very low-level-y directly, for example by programming WebAssembly Text (.wat) files directly and executing them with Wasmer. For example, as far as I can tell, the signature of the original, deprecated http_request function seems to be:

(import "wasix_32v1" "http_request" (func $http_request
	(param $url_string_ptr i32)
	(param $url_string_length i32)
	(param $method_string_ptr i32)
	(param $method_string_length i32)
	(param $headers_string_ptr i32)
	(param $headers_string_length i32)
	(param $gzip_enabled i32)
	(param $http_handle_ptr i32) ;; will be filled with an i32 handle id by the runtime
	(result i32) ;; zero (success) or error number
))

What is the equivalent for (the) current alternative(s)? I tried all sorts of things like (import "wasix_http_client_v1" "open" ...), none of which were successful. Digging through the source code of wasix-abi-rust and wasix-libc in the hope of reverse-engineering the function module and name revealed that they both still seem to use the old "wasix_32v1" "http_request" method.

By the way, I even had to dig through Wasmer's source code just to find out which module namespace WASIX uses until I found wasix_32v1. Why is this nowhere mentioned in the official WASIX docs? The public documentation and marketing of WASIX seems to be targeted exclusively at developers that use WASIX's pre-made tools for Rust and C/C++, not for people who are developing their own programming language, library, etc. that targets WASIX or people developing their own WASM runtime or WASI(X) browser shim/polyfill. All I need is knowing the module namespaces, function names, the parameters of the barebone WASI(X) calls, and the binary byte architecture of the structures that the pointers in the function arguments point to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants