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.

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.

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.

Now WordPress is downloaded while building the Docker image, and then the following files are copied or overwritten:

wordpress-patch
├── .htaccess
├── wp-config.php
├── wp-content
│   ├── database
│   │   └── .ht.sqlite
│   └── db.php
└── wp-includes
    ├── blocks.php
    └── functions.php

Here is the long-awaited PR allowing different Wasm modules and multiple configurations simultaneously. It aims to fix #6, #7, and #16.

In #6, we allow now to specify different Wasm modules to be used in other routes. For instance, now it’s possible with one-single Apache instance to load simultaneously the Wasm builds for the PHP and Python interpreters.

And in #7, we now allow specifying different per-route configurations to the same Wasm module. In this case, the Wasm binary is loaded in memory only once, and the different configurations are applied to the Wasm module per-HTTP request.

Combining all together, we can have a more flexible configuration such as:

<Location /wordpress>
    SetHandler wasm-handler
    WasmModule /var/www/modules/php7.4.32.wasm
    WasmDir    /tmp
    …
</Location>
 
<Location /python-app>
    SetHandler wasm-handler
    WasmModule /var/www/modules/python3.11.wasm
    WasmArg    /var/www/python-app/app.py
    …
</Location>
 
<Location /python-app2>
    SetHandler wasm-handler
    WasmModule /var/www/modules/python3.11.wasm
    WasmArg    /var/www/python-app2/app2.py
    …
</Location>

In addition, we have run some preliminary stress tests using ApacheBench and mod_wasm performs really great in both MPM event and MPM worker modes.

New functions will soon land in wasm_runtime.h due to implementing #6. So it's likely that some versions won't be compatible between them.

In this PR, a simple mechanism is implemented in Autoconf so when mod_wasm is checking for the availability of libwasm_runtime.so, it will also check for its version.

Missing feature #13 for reading the HTTP Request Body and putting it into WASI stdin so it can be accessible for the WebAssembly modules.

The code for reading the body at mod_wasm.so is very tricky. More info here:

• • https://httpd.apache.org/docs/trunk/developer/modguide.html (section: "Reading the request body into memory")
• • https://docstore.mik.ua/orelly/apache_mod/139.htm

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.

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.

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.

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.

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.

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.

@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?