Currently, only one Wasm module with a unique configuration can be loaded at a time.

At first glance, we might want to consider two different scenarios:

1. Different Wasm modules on the same Apache instance, each of them attached to a different route.
2. One Wasm module serving different routes, but with different configurations.

In this issue, we will focus on 1). See #7 for the scenario 2).

Different Wasm modules at the same time involve, at least:

• Data structures storing httpd.conf mod_wasm directives need to be duplicated (once per module).
• Data structures for WASI context need to be duplicated too (ie: stdout buffer)
• Incoming HTTP requests need to be routed to the right Wasm module.

A first goal for this feature could be to serve PHP and Python Wasm modules by only one Apache instance.

To manage the HTTP request body in Wasm, we need to pass it as the stdin to the WASI context.

Is your feature request related to a problem? Please describe.

Apache server's extension mechanism works through modules written in C:

• https://httpd.apache.org/docs/2.4/developer/modguide.html
• https://www.oreilly.com/library/view/writing-apache-modules/156592567X

Some modules, such as mod_lua or mod_perl, try to relax this requirement by exposing Apache's internal APIs to different programming languages.

We aim to expand these capabilities by allowing the possibility of rewriting any existing Apache module in any programming language that can target WebAssembly (ie: Rust, Go, etc.) or even interpreted languages (ie: Python, PHP, Ruby, etc.).

Describe the solution you'd like

The initial version of mod_wasm was created with the purpose of serving content from WebAssembly binaries, enabling the execution of traditional applications within a Wasm-based stack (ie: WordPress, Drupal, etc.).

This extensibility through mod_wasm requires Wasm modules to gain access to Apache’s internal API through host functions, as well as a mechanism to hook into the different HTTP request stages. We don’t need to expose the entire Apache’s API; a core subset may be enough (ie: exposed data structures and built-in functions in mod_lua).

By compiling these new modules to WebAssembly, they can effectively work as traditional Apache modules for activities such as monitoring, modifying headers, filtering requests, security, etc. all while benefiting from the safety provided by the Wasm sandboxing model and being coded in your preferred programming language. More importantly, a programming bug in a module (ie: segfault) won’t crash the entire Apache server as currently happens when the module is natively compiled into a .so library.

Describe alternatives you've considered

Exposing the entire Apache API to mod_wasm would require a significant effort. Instead, it would be more practical to select a subset that can provide new features. Examples include reading and modifying headers, registering hooks, and supporting the proxy-wasm specification. Then, encourage the community to keep implementing the remaining APIs for other use cases.

Regarding the Apache API, @assambar submitted a PoC (PR#55) demonstrating how to manage headers from a Wasm module. In addition, @gzurl submitted another PoC (PR#57) to showcase how Wasm exported functions can be automatically registered into Apache’s hooks without any extra boilerplate code. By combining and integrating these two PoCs in a robust manner and extending the exposed Apache APIs, we can develop a new mod_wasm version where Wasm modules can replace certain functionality from the traditional Apache modules.

Additional context

We propose three iterations to achieve this goal:

Iteration 0: Define new directives and configuration features:

• New Apache directives will be needed to distinguish the kind of Wasm modules to run (content handler or extension) and the group of host functions to enable (ie: WasmModule, WasmApacheModule, …)
• Also, existing Wasm directives (ie: WasmDir, WasmEnv, …) will need to be applied to different Wasm module types.
• This iteration is also a good opportunity to refactor the current code to make room for the upcoming features. Also, invest some time in missing CI common stuff that will be certainly needed in future iterations (E2E “Hello, Wasm!” test (#11), automate releases, etc).

Iteration 1: Implement new directives, self-registered hooks and expose request_recstructure:

• HTTP requests' data will be passed to the new Apache Wasm modules in read-only mode (actually, not providing manipulation functions). This enables use cases such as simple firewall-like functionality.
• In this iteration, we will need to create an apache_bindings.rs Rust module (or crate) to access the Apache API’s data structures (ie: request_rec, etc.). This will probably be the seed of the apache-wasm-rust-sdk. We should try hard to use bindgen for exposing C structures into Rust instead of manual migration. We will appreciate that later.
• Also, during this iteration, we can start dealing with a quick and efficient manner to access the headers and body without copying strings back and forth.

Iteration 2: Add support for host functions and expose basic Apache APIs

• This iteration is about evolving from read-only to read-write operations, where specific host functions wrapping the Apache API will be required.
• New exposed Apache APIs come from simple ap_log_*, to more complex apr_table_* functions, enabling request and response manipulation.
• At this point, we should be showcasing a similar (but limited) functionality to other modules like mod_lua or mod_tcl. And offering the capability to reimplement modules like mod_headers or even mod_rewrite.

Is your feature request related to a problem? Please describe.

The wasm_runtime.so Rust library is at the core of mod_wasm.
https://github.com/vmware-labs/mod_wasm/tree/main/wasm_runtime/src

Beyond unit tests (described at #62), integration tests are also needed to harden its stability.

Describe the solution you'd like

The integration tests should invoke all functions in the C API (see c_api.rs).

Originally, minimal integration tests were included only for wasm_config_create():
https://github.com/vmware-labs/mod_wasm/blob/main/wasm_runtime/tests/integration_tests.rs

The integration tests for this library should be increased for all the functions in the C API.

Describe alternatives you've considered

No response

Additional context

No response

This feature request comes originally from #6.

In this case, we might want the same Wasm module to be used in different routes but with different configurations (ie: different WasmMapDir directives, etc.). The reason to use the same Wasm module is to save memory by not loading the same module several times.

@ereslibre suggested adding support for pulling the Wasm modules from a remote source.
This way, httpd.conf files can be redistributed without the Wasm modules.

@ereslibre, could you please add more detail?

Is your feature request related to a problem? Please describe.

Proxy-wasm is an ABI spec for proxy's extensibility using WebAssembly modules, originally developed for the Wasm in Envoy project.

Proxy-wasm is an event-driven API, meaning that the Wasm module gets notified for events in which showed interest (by exporting the proper functions). Next, the module can decide whether to react to those events or not. As an example, the host will invoke proxy_on_http_request_headers into the Wasm module when headers are received from the client. Then, the Wasm module can invoke proxy_get_map on the host to retrieve the headers.

As an example, an interesting use case that could benefit from proxy-wasm support in Apache is Project Coraza, a WAF compatible with ModSecurity. There is a proxy-wasm wrapper (coraza-proxy-wasm) that could be run into mod_wasm.

Describe the solution you'd like

It could be interesting to leverage the works in #59: "Ability to extend Apache server with Wasm modules".
Similarly, we don’t need to fully implement the whole spec (that BTW is under active discussion: #38, #40, #41).

Some related project that implements part of the spec:

• The Wasm extension for Nginx (wasm-nginx-module), used in Apache APISIX.
• Kong’s proxy-wasm implementation for Nginx (aka WasmX).
• The coraza-proxy-wasm filter for Envoy.
• The Envoy proxy-wasm extension.

Given the proxy-wasm level of compliance of these projects, it seems reasonable to start providing limited proxy-wasm support in mod_wasm, initially in parity with Nginx/APISIX. Next, increase support to run Coraza WAF, and finally to be compatible with Envoy filters.

Describe alternatives you've considered

No response

Additional context

We propose four iterations to achieve this goal, that continue the works of the iterations proposed at #59:

Iteration 3: Integrate proxy-wasm-rust-sdk.

• In this iteration, we start working on implementing proxy-wasm.
• The Apache APIs exposed (from #59) include most of the requirements needed to run all the examples in the SDK repo.
• Additionally, we will need to implement specific support for non-Apache related stuff (ie: proxy_on_tick).
• At the end of this iteration, we should be able to execute simple proxy-wasm modules.

Iteration 4: Implement proxy-wasm to support wasm-nginx (APISIX) tests.

• Upon this iteration, we should provide proxy-wasm support on parity with Nginx. So, APISIX proxy-wasm modules should be able to run in mod_wasm.

Iteration 5: Implement proxy-wasm to run coraza-proxy-wasm.

• This iteration will add additional functionality to run Coraza as a proxy-wasm filter.

Iteration 6: Implement proxy-wasm to pass envoy tests (#1, #2, #3).

• In this final iteration, mod_wasm supports all proxy-wasm tests from Envoy.

Describe the bug

When working on the Drupal demo and enabling libpng, found that the PHP Wasm module can return binaries via stdout, including non-UTF-8 valid sequences or C NULL-terminator characters (\0).

ERROR: C-API: Can't run Wasm execution context '3485D80B'! "ERROR! Can't convert stdout to UTF-8 string! invalid utf-8 sequence of 1 bytes from index 373"
[Thu Feb 23 19:42:56.484197 2023] [core:error] [pid 3825:tid 281472342552768] [client 172.17.0.1:56372] Premature end of script headers: index.php, referer: http://localhost:8080/drupal/node/1/edit

This is due to read_stdout() transforming the stdout into a Rust String (that must be UTF-8 encoded):

Reproduction steps

N/A

Expected behavior

A Wasm module should be able to return any output in any format, including binaries (ie.: .png file).

Additional context

No response

When executing a Wasm module, _start is the function executed by default.

We might want to invoke different entry points into a single module.
A new directive (i.e.: WasmEntryPoint ) could do the job.

Currently, only Wasmtime engine is supported.

We might want to support others like:

• WasmEdge
• WebAssembly Micro Runtime (WAMR)
• Wasmer
• Etc.

This way, we allow the developer to take advantage of the specific Wasm engine's unique features.

Ideally, a new directive such as WasmEngine <engine_name> could be used for each module that has to be loaded. This enables a quick way to test a module with one engine or another.

One relevant aspect to be considered is to have a kind of engine-feature matrix, so in case a WasmFeatureX is not supported by a specific engine, then maybe Apache shouldn't boot up.

At httpd.conf, we might have different <Location> groups that overlap with each other:

<Location /python_apps/app_1>
   WasmModule /var/www/modules/python3.11
</Location>

<Location /python_apps/app_2>
   WasmModule /var/www/modules/python3.12
</Location>

<Location /python_apps>
   WasmModule /var/www/modules/python3.11
</Location>

The latest <Location> group above will shadow the other more specific configurations.

This can be solved by adding support for merge configurations in mod_wasm.c.

Currently, only one Vector<u8> is used as a buffer to manage the stdout from the Wasm module.

This becomes a bottleneck since Apache can run several workers at a time, but if they receive requests to the Wasm endpoint, then each worker will have to wait until getting mutual exclusion over the buffer.

A minimal E2E (end-to-end) testing would be using the demo container but with the mod_wasm.so and libwasm_runtime.so libraries built with the new code.

The test could be as simple as executing a curl over an endpoint served by the Wasm module in Apache and checking for its result.

The 'PrettyFy' WebApp could be a nice target since it requires the Python interpreter as the Wasm module: curl -vvv http://127.0.0.1:8080/wasm-module?file=search_word_count.py

Also, running the Apache Benchmark tool (in httpd/dist/bin) with a few tests in parallel could help to identify potential problems with the mutexes:
./ab -n 100 -c 10 http://192.168.64.2:8080/wasm-module?file=search_word_count.py

This basically implies:

• mod_wasm.so is generated in the format Apache for Windows requires.
• libwasm_runtime.so is generated for Windows.

@ereslibre initiated an interesting discussion about the return value types in the C API.

Currently, some functions return a *const c_char as a result:

pub extern "C" fn wasm_executionctx_run(executionctx_id: *const c_char) -> *const c_char
pub extern "C" fn wasm_executionctx_create_from_config(config_id: *const c_char) -> *const c_char {

So there is no formal way to distinguish whether the returned data is the expected output or a text explaining the error.

We should explore returning a CResult that looks like this:

struct CResult {
  bool succeeded;
  char *result;
};

Or we could go for this other approach of result-type-in.c.

An example of mod_wasm.c code that is missing error logging is the Wasm execution invocation. We don't know if the returned string was the expected output or not.

const char* module_response = wasm_executionctx_run(exec_ctx_id);

In any case, we should take care of returning the string ownership to Rust.

I am opening this issue to have a discussion about it.

Is your feature request related to a problem? Please describe.

Currently, if a lock is poisoned on the Rust side, the code will panic.
We might want to improve this behavior by returning an error.

See the original discussion at #41 (comment)

Since there is some literature written and different options about how to deal with poisoned locks, I'm opening this issue for an open discussion.

Describe the solution you'd like

@ereslibre suggested:

let mut executionctxs = WASM_RUNTIME_EXECUTIONCTXS.write().map_err(|e| format!("error: {:?}", e))?;

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

Enable GitHub Actions to automatically build the release binaries upon new tag in the main branch.

Releases should include:

• Linux/x86_64
• Linux/arm64
• Windows (x86_64)

Describe the solution you'd like

The Rust wasm_runtime.so library, can be built in both Linux and Windows (and macOS) just by using cargo.

The C mod_wasm.so library build can be tricky to automate in Windows.
Some preliminary works here: gzurl#1

Additional references:

• https://github.com/marketplace/actions/setup-msys2
• https://packages.msys2.org/package/?repo=mingw64
• https://github.com/cloudflare/quiche/pull/1072/files

Describe alternatives you've considered

No response

Additional context

No response

Describe the bug

In execution_ctx.rs run() method, the WASM_RUNTIME_EXECUTIONCTXS hash map is locked as read() during the Wasm module execution.

This means new threads (new HTTP incoming requests) can't create new execution contexts since that would require exclusive write() access.

In a 'normal' scenario, this is suboptimal because it might lead to a situation where Apache is allocating more resources than mod_wasm can leverage.

But in an adverse scenario, if a Wasm module execution takes longer than usual (or hangs up), that might block other incoming requests.

Since CPU-limited executions are not implemented yet (see #9), it would be much better to ensure that the WASM_RUNTIME_EXECUTIONCTXS hash map is not locked at all during the Wasm module execution.

Reproduction steps

1. Create a configuration with two different locations:
   • a) /intense_task, whose Wasm execution takes a long time (ie: 10secs)
   • b) /light_task, a very simple and immediate task
2. Start up Apache and check both locations works as expected.
3. Then load /intense_task, and right after, try loading /light_task: It should be obvious that such /light_task won't start until /intense_task is done.

Expected behavior

In a mono-thread scenario (ie.: httpd -X), new requests are queued and dispatched one by one.
In a multi-threading scenario, new requests shouldn't be delayed because other requests are running the Wasm module.

Additional context

This issue was reported by @juamedgod, who noticed a wrong behavior while testing a dev version of PHP.wasm whose execution never finished. Thanks for reporting!!

At least, a build action should be triggered when a new pull request is submitted.

Ideally, and in addition, a minimal unit test over Rust code should run using cargo test.

Is your feature request related to a problem? Please describe.

The wasm_runtime.so Rust library is at the core of mod_wasm.
https://github.com/vmware-labs/mod_wasm/tree/main/wasm_runtime/src

Thus, it requires minimal unit tests to harden its stability.

Describe the solution you'd like

Originally, minimal unit tests were included for the low-level const_c_char_to_str() at ffi_utils.rs.
The unit tests coverage for this library should be increased in all files.

• ffi_utils.rs
• c_api.rs
• config.rs
• module.rs
• wasi_ctx.rs
• wasm_engine.rs
• execution_ctx.rs

Describe alternatives you've considered

No response

Additional context

No response

Wasmtime allows AOT (ahead-of-time) compilation.
We might want to enable it and test whether it brings better performance.

If so, we would need to decide whether it's enabled or disabled by default.

This is a very interesting and promising feature but it requires a long discussion about how to implement it.

At first glance, it seems we might want to enable/disable features depending on some input.
For instance, set a WasmMapDir to a value depending on an HTTP Request concrete header and its value.

The big question is how to define (syntax) these conditions in the httpd.conf.

This feature could be very relevant when running untrusted third-party code.

In Wasmtime, this could be achieved via:
https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel

Depending on the configuration, during the boot up, Apache Server performs a dry-run over httpd.conf and then if everything went well then executes a second pass over httpd.conf.

A dry run for Apache Server means directives are invoked but they shouldn't have any effect. Currently, we do not support this in mod_wasm.c, and the side effect is the next warning:

./httpd -X
[Thu Nov 17 11:51:04.318334 2022] [wasm:notice] [pid 13747:tid 281472847323168]
[Thu Nov 17 11:51:04.318630 2022] [so:warn] [pid 13747:tid 281472847323168] AH01574: module wasm_module is already loaded, skipping`

As a consequence, wasm_runtime is also trying to load Wasm modules twice. In this case, either 1) mod_wasm emits a "Wasm module already loaded" warning message, or 2) we turn off that check and then we cannot really identify such a doubled-load scenario.

While this is not supported, the doubled-load check in pub fn from_file() in module.rs won't emit any warning.

Currently, when building the WASI context for the Wasm module, it inherits stderr from the Apache process. So all the output to stderr becomes part of the Apache's error_log file, but it's not really integrated into the Apache trace.

NOW:

[Tue Sep 06 20:09:17.733094 2022] [core:notice] [pid 2074:tid 140335383988096] AH00094: Command line: './httpd'
Hello, Wasm! (@stderr)

DESIRED:

[Tue Sep 06 20:09:17.733094 2022] [core:notice] [pid 2074:tid 140335383988096] AH00094: Command line: './httpd'
[Tue Sep 06 20:09:17.749431 2022] [core:notice] [pid 2074:tid 140335383988096] Hello, Wasm! (@stderr)

To solve this, we can replicate the implementation for stdout, by having a new Vec<u8> buffer and another WritePipe for the WasiCtx.

But the main difference with stdout is when to read it. The stdout is read at the end of the execution (and that seems fine). On the other hand, we might want an error sent to stderr to be printed out to the trace as soon as it happens, so it also gets the right time marks.

So, there is no straightforward solution: either we somehow 'listen' to the pipe for new lines, or we might need to read on a time basis (every second?) and pull for new lines during the Wasm execution.

Also, we need to consider how it is returned from wasm_runtime.so to mod_wasm.so; probably by returning a struct to C, so wasm_runtime_run_module() -> *const c_char would become kind of wasm_runtime_run_module() -> struct stdio { *const c_char, *const c_char }. In this regard, this issue is related to #4 since it requires solving how structs can be returned from Rust to C.

Describe the bug

First of all, thank you for this awesome project!

I followed the Installation steps for Windows, downloaded the examples and tried my best to get the php examples running but I get the following error message using this location:

<Location /php-hello>
        AddHandler wasm-handler .php
        WasmModule D:/wasmer/php-cgi-8.2.0.wasm
        WasmDir    /tmp
        WasmEnv TMPDIR /tmp
        WasmMapDir / /
        WasmEnableCGI On
</Location>

Message:

[Sat Sep 30 19:05:32.778156 2023] [mpm_winnt:notice] [pid 34536:tid 336] AH00354: Child: Starting 64 worker threads.
ERROR! C-API: Can't run Wasm execution context 'E8A405B1'! "ERROR! Invocation of function '_start' failed! Wasm Trap returned! error while executing at wasm backtrace:\n    0: 0x8f8afe - <unknown>!<wasm function 11722>\n    1: 0xbadd - <unknown>!<wasm function 38>\n\nCaused by:\n    exit with invalid exit status outside of [0..126)"
[Sat Sep 30 19:05:37.331759 2023] [wasm:error] [pid 34536:tid 1020] (-1)Unknown error: [client ::1:54591] content_handler() - ERROR! Couldn't run Wasm execution context 'E8A405B1'!
[Sat Sep 30 19:05:37.331759 2023] [core:error] [pid 34536:tid 1020] [client ::1:54591] End of script output before headers: index.php
[Sat Sep 30 19:05:37.331759 2023] [wasm:error] [pid 34536:tid 1020] (500)Unknown error: [client ::1:54591] ERROR! Invalid script response. On header #0, found character '(null)': 
[Sat Sep 30 19:05:37.331759 2023] [wasm:error] [pid 34536:tid 1020] (500)Unknown error: [client ::1:54591] ERROR! Couldn't find mandatory 'Content-type' HTTP header (i.e.: "Content-type: text/html\n\n")

I manged to see a result using this Location with WasmEnableCGI = Off

<Location /php-hello2>
        AddHandler wasm-handler .php
        WasmModule D:/wasmer/php-cgi-8.2.0.wasm
        WasmArg    /index.php
        WasmMapDir / D:/webassambly/htdocs/php-hello2
        WasmEnableCGI Off
</Location>

Result (truncated):

X-Powered-By: PHP/8.2.0
Content-type: text/html; charset=UTF-8


<html>
    <body>
        <h1>Hello from PHP on Wasm!</h1>
        Today, Saturday, 2023-9-30, at 21:30:39 we greet you with this message!<h1>Output from phpinfo():</h1>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml">
            <head>
                <style type="text/css">
                    body {
                        background-color: #fff;
                        color: #222;
                        font-family: sans-serif;
                    }
...

The non php exapmles like http-request-viewer run just fine.

I don't know, if this is a bug or a wrong configuration.

Reproduction steps

1. Download apache httpd version 2.4.57 for Windows
2. Download the mod_wasm for Windows from the apachelounge website in version 0.12.1
3. use the provided httpd.conf from this project
4. Edit the config to match your local filesystem
5. Start apache httpd.exe
6. Browse the php-hello website

Expected behavior

The Hello from PHP on Wasm! message and the phpinfo() html is shown

Additional context

I also tried wasmer using this wasmer.toml:

[package]
name = "wasmer/php-hello"
version = "0.0.1"
description = "A PHP template for WCGI applications"
license = "MIT OR Apache-2.0"
readme = "README.md"
repository = "https://github.com/wasmerio/wcgi-php-template"

[[module]]
name = "php"
source = "php-cgi-8.2.0.wasm"
abi = "wasi"

[[command]]
name = "php"
runner = "wcgi"
module = "php"

[command.annotations.wcgi]
dialect = "rfc-3875"

[command.annotations.wasi]
atom = "php"
env = ["DOCUMENT_ROOT=/app", "SCRIPT_FILENAME=/app/index.php"]

[fs]
"app" = "app"

Running wasmer with this command

wasmer run-unstable .

returns the expected result.
So php-cgi-8.2.0.wasm is fine but I don't have any idea what causes the issue.

The current build status is:

• ✅ x86_64 / darwin
• ✅ x86_64 / gnu-linux
• ✅ aarch64 / darwin
• ❌ aarch64 / gnu-linux

The build error is:

error[E0308]: mismatched types
  --> src/ffi_utils.rs:64:55
   |
64 |         let cstring_to_deallocate = CString::from_raw(ptr as *mut i8);
   |                                     ----------------- ^^^^^^^^^^^^^^ expected `u8`, found `i8`
   |                                     |
   |                                     arguments to this function are incorrect
   |
   = note: expected raw pointer `*mut u8`
              found raw pointer `*mut i8`
note: associated function defined here

For more information about this error, try `rustc --explain E0308`.
error: could not compile `wasm_runtime` due to previous error

I suspect that c_char alias is working differently for aarch64/gnu-linux than for aarch64/darwin.

Is your feature request related to a problem? Please describe.

As part of PR #41, @ereslibre suggested this change: #41 (comment)

Describe the solution you'd like

Using primitive numbers instead of String objects will avoid all clone() operations needed right now. So it will use less memory and copy primitives will consume less CPU.

So far, we were using 8 hex chars, so 16^8 = 4.294.967.296 combinations. This is precisely the same that using a u32.

Describe alternatives you've considered

No response

Additional context

No response

Describe the bug

Testing mod_wasm 0.11.2 on Windows we got a "Permission denied" error while opening directories, while reading files under those directories work fine.

Reproduction steps

See details at bytecodealliance/wasmtime#6348

Expected behavior

See details at bytecodealliance/wasmtime#6348

Additional context

No response

Is your feature request related to a problem? Please describe.

Issue requested by Dependabot: https://github.com/vmware-labs/mod_wasm/security/dependabot/3

Describe the solution you'd like

Update Wasmtime to 8.0.1 to address this low-severity CVE: GHSA-ch89-5g45-qwc7

Describe alternatives you've considered

No response

Additional context

No response

Today, we use wasmtime::Engine::default() to get an Engine instance.
Many parameters could be configured to load an Engine instance and they should be available from httpd.conf.

Describe the bug

It gives an error while building like

root@demo:/home/nrathi/mod_wasm/mod_wasm# ./build.sh
SUDO_GID=1000
LESSOPEN=| /usr/bin/lesspipe %s
MAIL=/var/mail/root
USER=root
SHLVL=1
HOME=/root
OLDPWD=/home/nrathi/mod_wasm
LC_CTYPE=C.UTF-8
SUDO_UID=1000
LOGNAME=root
_=./build.sh
TERM=xterm-256color
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LANG=C.UTF-8
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arc=01;31:.arj=01;31:.taz=01;31:.lha=01;31:.lz4=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.tzo=01;31:.t7z=01;31:.zip=01;31:.z=01;31:.dz=01;31:.gz=01;31:.lrz=01;31:.lz=01;31:.lzo=01;31:.xz=01;31:.zst=01;31:.tzst=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.alz=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.cab=01;31:.wim=01;31:.swm=01;31:.dwm=01;31:.esd=01;31:.jpg=01;35:.jpeg=01;35:.mjpg=01;35:.mjpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.m4a=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.oga=00;36:.opus=00;36:.spx=00;36:*.xspf=00;36:
SUDO_COMMAND=/bin/bash
SHELL=/bin/bash
SUDO_USER=nrathi
LESSCLOSE=/usr/bin/lesspipe %s %s
PWD=/home/nrathi/mod_wasm/mod_wasm
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop

• which libtool
  /usr/bin/libtool
• which pkg-config
  /usr/bin/pkg-config
• echo [Building mod_wasm]
  [Building mod_wasm]
• pwd
• dirname -- ./build.sh
• cd -- .
• SCRIPT_DIR=/home/nrathi/mod_wasm/mod_wasm
• realpath /home/nrathi/mod_wasm/mod_wasm/modules/wasm
• MOD_WASM_DIR=/home/nrathi/mod_wasm/mod_wasm/modules/wasm
• realpath /home/nrathi/mod_wasm/mod_wasm/../wasm_runtime
• WASM_RUNTIME_PATH=/home/nrathi/mod_wasm/wasm_runtime
• realpath /home/nrathi/mod_wasm/mod_wasm/../dist
• DIST_DIR=/home/nrathi/mod_wasm/dist
• [ -z ]
• realpath ../httpd
• HTTPD_DIR=/home/nrathi/mod_wasm/httpd
• uname -m
• ARCH=x86_64
• echo [Deleting binaries]
  [Deleting binaries]
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/mod_wasm.o
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/mod_wasm.lo
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/mod_wasm.slo
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/mod_wasm.la
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/.libs/mod_wasm.o
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/.libs/mod_wasm.la
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/.libs/mod_wasm.lai
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/.libs/mod_wasm.a
• rm -fv /home/nrathi/mod_wasm/mod_wasm/modules/wasm/.libs/mod_wasm.so
• echo [Building mod_wasm]
  [Building mod_wasm]
• echo [mod_wasm: compiling]
  [mod_wasm: compiling]
• cd /home/nrathi/mod_wasm/mod_wasm/modules/wasm
• pkg-config --cflags apr-1 apr-util-1
• /usr/share/apr-1.0/build/libtool --verbose --mode=compile x86_64-linux-gnu-gcc -I/home/nrathi/mod_wasm/httpd -DLINUX -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apr-1.0 -I/home/nrathi/mod_wasm/wasm_runtime/include -shared -c mod_wasm.c
  libtool: compile: x86_64-linux-gnu-gcc -I/home/nrathi/mod_wasm/httpd -DLINUX -D_REENTRANT -D_GNU_SOURCE -I/usr/include/apr-1.0 -I/home/nrathi/mod_wasm/wasm_runtime/include -c mod_wasm.c -fPIC -DPIC -o .libs/mod_wasm.o
  mod_wasm.c:16:10: fatal error: httpd.h: No such file or directory
  16 | #include "httpd.h"
  | ^~~~~~~~~
  compilation terminated.
• echo [mod_wasm: linking]
  [mod_wasm: linking]
• /usr/share/apr-1.0/build/libtool --verbose --mode=link x86_64-linux-gnu-gcc -L/home/nrathi/mod_wasm/wasm_runtime/target/release -lwasm_runtime -o mod_wasm.la -rpath /dist/modules -module -avoid-version mod_wasm.lo
  libtool: error: 'mod_wasm.lo' is not a valid libtool object
• echo [Installing module]
  [Installing module]
• mkdir -p /home/nrathi/mod_wasm/dist/modules/
• cp -v .libs/mod_wasm.so /home/nrathi/mod_wasm/dist/modules/
  cp: cannot stat '.libs/mod_wasm.so': No such file or directory
• echo [Installing httpd.conf]
  [Installing httpd.conf]
• cd /home/nrathi/mod_wasm/mod_wasm
• mkdir -p /home/nrathi/mod_wasm/dist/conf/
• cp -v httpd.conf /home/nrathi/mod_wasm/dist/conf/

Reproduction steps

...

Expected behavior

Need to manually edit the build script and provided the path for httpd.h

like
echo "[Building mod_wasm]"

SCRIPT_DIR=$( cd -- "$(dirname -- "$0")" &> /dev/null && pwd )
MOD_WASM_DIR=${MOD_WASM_DIR:-$(realpath "${SCRIPT_DIR}/modules/wasm")}
WASM_RUNTIME_PATH=${WASM_RUNTIME_PATH:-$(realpath "${SCRIPT_DIR}/../wasm_runtime")}
DIST_DIR=${DIST_DIR:-$(realpath "${SCRIPT_DIR}/../dist")}
if [ -z ${HTTPD_DIR+x} ]
then

HTTPD_DIR=$(realpath ../httpd)

**HTTPD_DIR=/usr/include/apache2/**

fi
ARCH=$(uname -m)

echo "[Deleting binaries]"

rm -fv ${MOD_WASM_DIR}/mod_wasm.o
rm -fv ${MOD_WASM_DIR}/mod_wasm.lo
rm -fv ${MOD_WASM_DIR}/mod_wasm.slo
rm -fv ${MOD_WASM_DIR}/mod_wasm.la

Additional context

No response

From @ereslibre at #22 (HTTP Request Body to WASI stdin):

I think we could get rid of the max body limitation if we follow mod_cgi's approach.

They call to cgi_handle_request. It reads the request body and writes it to a file descriptor. We could use this file descriptor to pass the body of the request to wasi_stdin instead of building an ad-hoc pipe.

I think it would be feasible, but haven't checked it.

I believe it could be worth it to take a look at this.