Re: mod_wasm: Contributing Upstream to Apache

2023-07-07 Thread Joe Schaefer
All good.  Just didn’t want to see needless delays in getting this stuff
incorporated while you build out the non-content handler mode for mod_wasm
that IMO will never be in big demand (if it were, mod_perl wouldn’t be such
a stagnant community over the past two decades).

On Fri, Jul 7, 2023 at 4:07 PM Jesús González  wrote:

> Joe, thanks for your feedback!
>
>
>
> Just to make sure I understand this feedback, what you are mentioning is
> that exposing the internals of Apache diminishes the value of the sandbox
> because programs could potentially perform write operations into the
> internals of httpd state, tables, etc. Is that correct?
>
>
>
> If my understanding is correct, this should not be an issue:
>
>
>
> - The current incarnation of mod_wasm is implemented as a content-handler
> and does not have access to the internals of Apache or tables. All the
> information is passed through environment variables, similar to a
> traditional CGI binary, but running in the Wasm sandbox (so you can control
> tightly any access to filesystem, network, etc.).
>
>
>
> - The proposed changes to mod_wasm that enable writing Apache modules in
> other languages would expose the API, but that’s the idea: to make it easy
> to build fully featured Apache modules using any language that can compile
> to Wasm (ie: Go, Python). Think of this as an ‘universal’ polyglot version
> of mod_lua with added sandboxing capabilities.
>
>
>
> Which mode to use can be configured. You definitely don’t want random
> users having access to the internals of httpd when serving their regular
> application (ie: Drupal).
>
>
>
> Having said all of this, regarding the read-only structs, a Wasm binary
> cannot access the host memory space. So, a pointer to an apr table in the
> httpd memory space cannot be dereferenced within the sandbox. There exist
> opaque reference types (ie: externref) to host objects that comply with
> WebAssembly sandboxing guarantees as explained in
> https://fitzgeraldnick.com/2020/08/27/reference-types-in-wasmtime.html.
> This is great in terms of security, but a drawback from a performance
> perspective. To manipulate data structs, either they are copied into the
> Wasm memory and copied back to the server, or we offer a set of limited
> interfaces to the Wasm binary to perform such actions. So yes, we believe
> your proposal of getting the apreq_* (ARP table-based) interfaces exposed
> as read-only data structures is doable and useful.
>
> Cheers!
>
>
>
> *De: *Joe Schaefer 
> *Fecha: *miércoles, 5 de julio de 2023, 4:59
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> The win with having an apr table  api from httpd is that by sharing those
> tables in the sandbox, various programming languages will be able to
> interact with others without stealing the client form inputs.
>
>
>
> Even if you don’t go that route, and just expose the form inputs on stdin
> in your app, users can always configure apreq’s input filter to activate on
> the protocol filter chain before wasm activates. That way other modules
> still can access form input without breaking the Wasm app.
>
>
>
> On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer  wrote:
>
> The more of the API you expose, the less value the sandbox has to end
> users.  For Webapps, easy read/search / write/ iterate is essential.  But
> also form data; which apreq stores in readonly apr tables.
>
>
>
> Joe Schaefer, Ph.D
>
> 
>
> +1 (954) 253-3732
>
> SunStar Systems, Inc.
>
> *Orion - The Enterprise Jamstack Wiki*
>
>
> --
>
> *From:* Jesús González 
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González 
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This

Re: mod_wasm: Contributing Upstream to Apache

2023-07-07 Thread Jesús González
Joe, thanks for your feedback!

Just to make sure I understand this feedback, what you are mentioning is that 
exposing the internals of Apache diminishes the value of the sandbox because 
programs could potentially perform write operations into the internals of httpd 
state, tables, etc. Is that correct?

If my understanding is correct, this should not be an issue:

- The current incarnation of mod_wasm is implemented as a content-handler and 
does not have access to the internals of Apache or tables. All the information 
is passed through environment variables, similar to a traditional CGI binary, 
but running in the Wasm sandbox (so you can control tightly any access to 
filesystem, network, etc.).

- The proposed changes to mod_wasm that enable writing Apache modules in other 
languages would expose the API, but that’s the idea: to make it easy to build 
fully featured Apache modules using any language that can compile to Wasm (ie: 
Go, Python). Think of this as an ‘universal’ polyglot version of mod_lua with 
added sandboxing capabilities.

Which mode to use can be configured. You definitely don’t want random users 
having access to the internals of httpd when serving their regular application 
(ie: Drupal).

Having said all of this, regarding the read-only structs, a Wasm binary cannot 
access the host memory space. So, a pointer to an apr table in the httpd memory 
space cannot be dereferenced within the sandbox. There exist opaque reference 
types (ie: externref) to host objects that comply with WebAssembly sandboxing 
guarantees as explained in 
https://fitzgeraldnick.com/2020/08/27/reference-types-in-wasmtime.html. This is 
great in terms of security, but a drawback from a performance perspective. To 
manipulate data structs, either they are copied into the Wasm memory and copied 
back to the server, or we offer a set of limited interfaces to the Wasm binary 
to perform such actions. So yes, we believe your proposal of getting the 
apreq_* (ARP table-based) interfaces exposed as read-only data structures is 
doable and useful.

Cheers!

De: Joe Schaefer 
Fecha: miércoles, 5 de julio de 2023, 4:59
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache
!! External Email
The win with having an apr table  api from httpd is that by sharing those 
tables in the sandbox, various programming languages will be able to interact 
with others without stealing the client form inputs.

Even if you don’t go that route, and just expose the form inputs on stdin in 
your app, users can always configure apreq’s input filter to activate on the 
protocol filter chain before wasm activates. That way other modules still can 
access form input without breaking the Wasm app.

On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
The more of the API you expose, the less value the sandbox has to end users.  
For Webapps, easy read/search / write/ iterate is essential.  But also form 
data; which apreq stores in readonly apr tables.

Joe Schaefer, Ph.D
mailto:j...@sunstarsys.com>>
+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Jesús González mailto:jesu...@vmware.com>>
Sent: Monday, July 3, 2023 8:49:33 AM
To: dev@httpd.apache.org<mailto:dev@httpd.apache.org> 
mailto:dev@httpd.apache.org>>
Subject: Re: mod_wasm: Contributing Upstream to Apache


Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> 
is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary 
support for WASI preview 2 among other improvements and fixes.

Best,
Jesús



De: Jesús González mailto:jesu...@vmware.com>>
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org<mailto:dev@httpd.apache.org> 
mailto:dev@httpd.apache.org>>
Asunto: Re: mod_wasm: Contributing Upstream to Apache

Thanks Joe for your encouragement! And yes, your feedback was what inspired us 
to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to 
WebAssembly get_header, set_header, delete_header, that internally make use of 
apr_table_get, apr_table_set and apr_table_unset with the incoming request 
headers (r->headers_in). This shows read and write capabilities from a Wasm 
binary using internal Apache APIs. Is this what you are referring to with 
exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality 
that is possible with other extension modules (mod_headers, mod_perl, mod_lua, 
etc.) won’t be available in mod_wasm. We would love to know more about those 
concerns, so we can understand better how to develop mod_wasm in a way that 
both allows you to develop fully capable modules but still address any concerns 
you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating 
vulnerabilities 
https://wasmlabs.dev

Re: mod_wasm: Contributing Upstream to Apache

2023-07-04 Thread Joe Schaefer
The win with having an apr table  api from httpd is that by sharing those
tables in the sandbox, various programming languages will be able to
interact with others without stealing the client form inputs.

Even if you don’t go that route, and just expose the form inputs on stdin
in your app, users can always configure apreq’s input filter to activate on
the protocol filter chain before wasm activates. That way other modules
still can access form input without breaking the Wasm app.

On Tue, Jul 4, 2023 at 10:48 PM Joe Schaefer  wrote:

> The more of the API you expose, the less value the sandbox has to end
> users.  For Webapps, easy read/search / write/ iterate is essential.  But
> also form data; which apreq stores in readonly apr tables.
>
> Joe Schaefer, Ph.D
> 
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> --
> *From:* Jesús González 
> *Sent:* Monday, July 3, 2023 8:49:33 AM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
>
> Hola!
>
> mod_wasm v0.12.1
> <https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> is now
> available!
>
> This maintenance release bumps Wasmtime to 10.0.1, including preliminary
> support for WASI preview 2 among other improvements and fixes.
>
> Best,
> Jesús
>
>
>
> *De: *Jesús González 
> *Fecha: *viernes, 2 de junio de 2023, 19:09
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> Thanks Joe for your encouragement! And yes, your feedback was what
> inspired us to expand mod_wasm in this direction.
>
> In the demo from my colleague Asen, we expose three wrapper functions to
> WebAssembly get_header, set_header, delete_header, that internally make use
> of apr_table_get, apr_table_set and apr_table_unset with the incoming
> request headers (r->headers_in). This shows read and write capabilities
> from a Wasm binary using internal Apache APIs. Is this what you are
> referring to with exposing apreq_*?
>
> Limiting to read-only (ie: just get_header) implies that some
> functionality that is possible with other extension modules (mod_headers,
> mod_perl, mod_lua, etc.) won’t be available in mod_wasm. We would love to
> know more about those concerns, so we can understand better how to develop
> mod_wasm in a way that both allows you to develop fully capable modules but
> still address any concerns you may have.
>
> BTW, here is a recent article showing how mod_wasm can help mitigating
> vulnerabilities
> https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/,
> proving how it adds an extra layer of security to traditional applications.
>
> Looking forward to your feedback.
>
>
> *De: *Joe Schaefer 
> *Fecha: *jueves, 1 de junio de 2023, 22:16
> *Para: *dev@httpd.apache.org 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
> *!! External Email*
>
> Huge fan, love that you are receptive to my feedback.  If you get to the
> point where the apreq_* (APR table-based) interfaces in trunk can be
> exposed as read-only data structures in mod_wasm as an optional API for
> power httpd users that like the sandboxed functionality you get OOTB, that
> would justify a lot of the more conservative concerns that some devs have
> for not putting incorporating this into the trunk codebase, which would be
> my recommendation at that point for how to get it into a releasable tree at
> some point.
>
>
>
>
>
> On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
> wrote:
>
> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would l

Re: mod_wasm: Contributing Upstream to Apache

2023-07-04 Thread Joe Schaefer
The more of the API you expose, the less value the sandbox has to end users.  
For Webapps, easy read/search / write/ iterate is essential.  But also form 
data; which apreq stores in readonly apr tables.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Jesús González 
Sent: Monday, July 3, 2023 8:49:33 AM
To: dev@httpd.apache.org 
Subject: Re: mod_wasm: Contributing Upstream to Apache


Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> 
is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary 
support for WASI preview 2 among other improvements and fixes.

Best,
Jesús



De: Jesús González 
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache

Thanks Joe for your encouragement! And yes, your feedback was what inspired us 
to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to 
WebAssembly get_header, set_header, delete_header, that internally make use of 
apr_table_get, apr_table_set and apr_table_unset with the incoming request 
headers (r->headers_in). This shows read and write capabilities from a Wasm 
binary using internal Apache APIs. Is this what you are referring to with 
exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality 
that is possible with other extension modules (mod_headers, mod_perl, mod_lua, 
etc.) won’t be available in mod_wasm. We would love to know more about those 
concerns, so we can understand better how to develop mod_wasm in a way that 
both allows you to develop fully capable modules but still address any concerns 
you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating 
vulnerabilities 
https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, 
proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.



De: Joe Schaefer 
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache

!! External Email

Huge fan, love that you are receptive to my feedback.  If you get to the point 
where the apreq_* (APR table-based) interfaces in trunk can be exposed as 
read-only data structures in mod_wasm as an optional API for power httpd users 
that like the sandboxed functionality you get OOTB, that would justify a lot of 
the more conservative concerns that some devs have for not putting 
incorporating this into the trunk codebase, which would be my recommendation at 
that point for how to get it into a releasable tree at some point.





On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
mailto:jcchav...@apache.org>> wrote:

I think not making WASM a first class concern in a proxy or server is missing 
out, more so in those platforms where extensibility isn't trivial. Apache will 
remain running in current setups but having limited extensibility is something 
concerning these days as systems are getting more and more complex. Writing an 
apache module isn't something you do every day and it probably takes quite some 
time, writing a wasm app following certain ABI is something you can do in 
minutes, hence supporting mod_wasm as a first class concern could be a good 
point in the sustainability of an ecosystem when it comes to moving forward out 
of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: 
> wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on 
> creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries 
> inside httpd, and we would like to contribute it upstream. Please see below 
> for more details. We would love to get your feedback and understand what 
> improvements would be needed (if any) before it could be considered for 
> contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction 
> format that is open, portable, efficient, secure, and polyglot. It originated 
> in the browser but is increasingly used in server applications, in particular 
> NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: 
> https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is 
> similar to how mod_php embeds a PHP runtime to run PHP code. This enables any 
> language that supports WebAssembly (including C++, Rust, Go but also Python, 
> PHP, Ruby) to run with mod_wasm and take advantage of the extra level of 
> security and

Re: mod_wasm: Contributing Upstream to Apache

2023-07-03 Thread Jesús González
Hola!

mod_wasm v0.12.1<https://github.com/vmware-labs/mod_wasm/releases/tag/v0.12.1> 
is now available!

This maintenance release bumps Wasmtime to 10.0.1, including preliminary 
support for WASI preview 2 among other improvements and fixes.

Best,
Jesús

De: Jesús González 
Fecha: viernes, 2 de junio de 2023, 19:09
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache
Thanks Joe for your encouragement! And yes, your feedback was what inspired us 
to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to 
WebAssembly get_header, set_header, delete_header, that internally make use of 
apr_table_get, apr_table_set and apr_table_unset with the incoming request 
headers (r->headers_in). This shows read and write capabilities from a Wasm 
binary using internal Apache APIs. Is this what you are referring to with 
exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality 
that is possible with other extension modules (mod_headers, mod_perl, mod_lua, 
etc.) won’t be available in mod_wasm. We would love to know more about those 
concerns, so we can understand better how to develop mod_wasm in a way that 
both allows you to develop fully capable modules but still address any concerns 
you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating 
vulnerabilities 
https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, 
proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.


De: Joe Schaefer 
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache
!! External Email
Huge fan, love that you are receptive to my feedback.  If you get to the point 
where the apreq_* (APR table-based) interfaces in trunk can be exposed as 
read-only data structures in mod_wasm as an optional API for power httpd users 
that like the sandboxed functionality you get OOTB, that would justify a lot of 
the more conservative concerns that some devs have for not putting 
incorporating this into the trunk codebase, which would be my recommendation at 
that point for how to get it into a releasable tree at some point.


On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
mailto:jcchav...@apache.org>> wrote:
I think not making WASM a first class concern in a proxy or server is missing 
out, more so in those platforms where extensibility isn't trivial. Apache will 
remain running in current setups but having limited extensibility is something 
concerning these days as systems are getting more and more complex. Writing an 
apache module isn't something you do every day and it probably takes quite some 
time, writing a wasm app following certain ABI is something you can do in 
minutes, hence supporting mod_wasm as a first class concern could be a good 
point in the sustainability of an ecosystem when it comes to moving forward out 
of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: 
> wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on 
> creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries 
> inside httpd, and we would like to contribute it upstream. Please see below 
> for more details. We would love to get your feedback and understand what 
> improvements would be needed (if any) before it could be considered for 
> contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction 
> format that is open, portable, efficient, secure, and polyglot. It originated 
> in the browser but is increasingly used in server applications, in particular 
> NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: 
> https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is 
> similar to how mod_php embeds a PHP runtime to run PHP code. This enables any 
> language that supports WebAssembly (including C++, Rust, Go but also Python, 
> PHP, Ruby) to run with mod_wasm and take advantage of the extra level of 
> security and sandboxing. To learn more about mod_wasm you can check out the 
> following resources:
>
>   *   An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/> for 
> the original release.
>   *   We presented mod_wasm at ApacheCon this year and here are the 
> slides<https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf<https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>>

Re: mod_wasm: Contributing Upstream to Apache

2023-06-02 Thread Jesús González
Thanks Joe for your encouragement! And yes, your feedback was what inspired us 
to expand mod_wasm in this direction.

In the demo from my colleague Asen, we expose three wrapper functions to 
WebAssembly get_header, set_header, delete_header, that internally make use of 
apr_table_get, apr_table_set and apr_table_unset with the incoming request 
headers (r->headers_in). This shows read and write capabilities from a Wasm 
binary using internal Apache APIs. Is this what you are referring to with 
exposing apreq_*?

Limiting to read-only (ie: just get_header) implies that some functionality 
that is possible with other extension modules (mod_headers, mod_perl, mod_lua, 
etc.) won’t be available in mod_wasm. We would love to know more about those 
concerns, so we can understand better how to develop mod_wasm in a way that 
both allows you to develop fully capable modules but still address any concerns 
you may have.

BTW, here is a recent article showing how mod_wasm can help mitigating 
vulnerabilities 
https://wasmlabs.dev/articles/mitigating-php-vulnerabilities-with-webassembly/, 
proving how it adds an extra layer of security to traditional applications.

Looking forward to your feedback.

De: Joe Schaefer 
Fecha: jueves, 1 de junio de 2023, 22:16
Para: dev@httpd.apache.org 
Asunto: Re: mod_wasm: Contributing Upstream to Apache
!! External Email
Huge fan, love that you are receptive to my feedback.  If you get to the point 
where the apreq_* (APR table-based) interfaces in trunk can be exposed as 
read-only data structures in mod_wasm as an optional API for power httpd users 
that like the sandboxed functionality you get OOTB, that would justify a lot of 
the more conservative concerns that some devs have for not putting 
incorporating this into the trunk codebase, which would be my recommendation at 
that point for how to get it into a releasable tree at some point.


On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
mailto:jcchav...@apache.org>> wrote:
I think not making WASM a first class concern in a proxy or server is missing 
out, more so in those platforms where extensibility isn't trivial. Apache will 
remain running in current setups but having limited extensibility is something 
concerning these days as systems are getting more and more complex. Writing an 
apache module isn't something you do every day and it probably takes quite some 
time, writing a wasm app following certain ABI is something you can do in 
minutes, hence supporting mod_wasm as a first class concern could be a good 
point in the sustainability of an ecosystem when it comes to moving forward out 
of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: 
> wasmlabs.dev<http://wasmlabs.dev/><https://wasmlabs.dev/>, a group focused on 
> creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly binaries 
> inside httpd, and we would like to contribute it upstream. Please see below 
> for more details. We would love to get your feedback and understand what 
> improvements would be needed (if any) before it could be considered for 
> contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly<https://webassembly.org/> (Wasm) is a new binary instruction 
> format that is open, portable, efficient, secure, and polyglot. It originated 
> in the browser but is increasingly used in server applications, in particular 
> NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: 
> https://apisix.apache.org/docs/apisix/wasm/).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is 
> similar to how mod_php embeds a PHP runtime to run PHP code. This enables any 
> language that supports WebAssembly (including C++, Rust, Go but also Python, 
> PHP, Ruby) to run with mod_wasm and take advantage of the extra level of 
> security and sandboxing. To learn more about mod_wasm you can check out the 
> following resources:
>
>   *   An overview article<https://wasmlabs.dev/articles/apache-mod-wasm/> for 
> the original release.
>   *   We presented mod_wasm at ApacheCon this year and here are the 
> slides<https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf<https://apachecon.com/acna2022/slides/01_Gonz%C3%A1lez_mod-wasm_Bringing_WebAssembly.pdf>>
>  and the source code: https://github.com/vmware-labs/mod_wasm.
>   *   CNCF Talk on mod_wasm showcasing how to run WordPress: 
> https://www.youtube.com/watch?v=jXe8kulUscQ
>
>
>
> In terms of mod_wasm architecture, the module is split into two parts:
>
>   *   mod_wasm.so is the extension module for Apache and it’s written in C.
>   *   An external dependency: libwasm_runtime

Re: mod_wasm: Contributing Upstream to Apache

2023-06-01 Thread Frank Gingras
As per the instructions:

To unsubscribe, send a messages to *users-unsubscr...@httpd.apache.org
* (or, if you are subscribed to the
digest version of the list, send to *users-digest-unsubscr...@httpd.apache.org
* ). You must send the
unsubscribe message from the same email address that you used to subscribe
to the list.

To complete the unsubscription process you must reply to a confirmation
email. If you do not receive this confirmation email, please check your
spam filters to see if they are capturing the message.


In this case, you would want to email dev-unsubscr...@httpd.apache.org





On Thu, Jun 1, 2023 at 4:32 PM Dan Ehrlich via dev 
wrote:

> Hi:
>
> Can I be unsubscribed from this list?
>
> Have sent previous messages following all the instructions on this page
> but to no avail:
> https://httpd.apache.org/userslist.html.
>
>
> Best,
>
> Dan
>
> On Fri, Jan 27, 2023 at 11:36 AM Jesús González 
> wrote:
>
>> Thanks Joe. You are correct, this initial implementation is the simplest
>> one to get it off the ground. We plan to continue development and add the
>> streaming functionality, which we know we will need for things like large
>> PDF file generation or support for Proxy-Wasm.
>>
>>
>>
>> Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool
>> feature that enables new possibilities like simultaneously supporting
>> multiple versions of PHP as well as better multi-tenancy (you will be able
>> to keep user's code and assets separate from each other using Wasm built-in
>> isolation mechanism).
>>
>>
>>
>> Regarding apreq, right now we have not had a need to use it as we pass
>> most of the headers and body to the runtimes themselves as the language
>> runtimes code for handling requests, etc. takes care of it as part of the
>> CGI implementation, etc. As we look to add different functionality (i.e.
>> extending Apache itself) we will probably provide access to it from Wasm.
>>
>>
>>
>>
>>
>> *De: *Joe Schaefer 
>> *Responder a: *"dev@httpd.apache.org" 
>> *Fecha: *jueves, 26 de enero de 2023, 5:17
>> *Para: *"dev@httpd.apache.org" 
>> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>>
>>
>>
>> Still, the idea is wicked cool if mod_wasm really can isolate the Python,
>> PHP, etc targets onto individual POSIX threads.
>>
>>
>>
>> Very exciting stuff for HTTP/2 Webapps.
>>
>


Re: mod_wasm: Contributing Upstream to Apache

2023-06-01 Thread Dan Ehrlich via dev
Hi:

Can I be unsubscribed from this list?

Have sent previous messages following all the instructions on this page but
to no avail:
https://httpd.apache.org/userslist.html.


Best,

Dan

On Fri, Jan 27, 2023 at 11:36 AM Jesús González  wrote:

> Thanks Joe. You are correct, this initial implementation is the simplest
> one to get it off the ground. We plan to continue development and add the
> streaming functionality, which we know we will need for things like large
> PDF file generation or support for Proxy-Wasm.
>
>
>
> Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool
> feature that enables new possibilities like simultaneously supporting
> multiple versions of PHP as well as better multi-tenancy (you will be able
> to keep user's code and assets separate from each other using Wasm built-in
> isolation mechanism).
>
>
>
> Regarding apreq, right now we have not had a need to use it as we pass
> most of the headers and body to the runtimes themselves as the language
> runtimes code for handling requests, etc. takes care of it as part of the
> CGI implementation, etc. As we look to add different functionality (i.e.
> extending Apache itself) we will probably provide access to it from Wasm.
>
>
>
>
>
> *De: *Joe Schaefer 
> *Responder a: *"dev@httpd.apache.org" 
> *Fecha: *jueves, 26 de enero de 2023, 5:17
> *Para: *"dev@httpd.apache.org" 
> *Asunto: *Re: mod_wasm: Contributing Upstream to Apache
>
>
>
> Still, the idea is wicked cool if mod_wasm really can isolate the Python,
> PHP, etc targets onto individual POSIX threads.
>
>
>
> Very exciting stuff for HTTP/2 Webapps.
>


Re: mod_wasm: Contributing Upstream to Apache

2023-06-01 Thread Joe Schaefer
Huge fan, love that you are receptive to my feedback.  If you get to the
point where the apreq_* (APR table-based) interfaces in trunk can be
exposed as read-only data structures in mod_wasm as an optional API for
power httpd users that like the sandboxed functionality you get OOTB, that
would justify a lot of the more conservative concerns that some devs have
for not putting incorporating this into the trunk codebase, which would be
my recommendation at that point for how to get it into a releasable tree at
some point.


On Tue, May 30, 2023 at 8:42 AM José Carlos Chávez 
wrote:

> I think not making WASM a first class concern in a proxy or server is
> missing out, more so in those platforms where extensibility isn't trivial.
> Apache will remain running in current setups but having limited
> extensibility is something concerning these days as systems are getting
> more and more complex. Writing an apache module isn't something you do
> every day and it probably takes quite some time, writing a wasm app
> following certain ABI is something you can do in minutes, hence supporting
> mod_wasm as a first class concern could be a good point in the
> sustainability of an ecosystem when it comes to moving forward out of the
> status quo.
>
> On 2022/11/14 06:37:34 Jesús González wrote:
> > Hi everyone,
> >
> >
> >
> > I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev<
> https://wasmlabs.dev/>, a group focused on creating open source tools for
> WebAssembly.
> >
> > We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would love to get your feedback and
> understand what improvements would be needed (if any) before it could be
> considered for contribution to the project.
> >
> >
> >
> >
> >
> > The details:
> >
> >
> >
> > WebAssembly (Wasm) is a new binary
> instruction format that is open, portable, efficient, secure, and polyglot.
> It originated in the browser but is increasingly used in server
> applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based
> plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/).
> >
> >
> >
> > mod_wasm is a way to run WebAssembly modules inside Apache Server. This
> is similar to how mod_php embeds a PHP runtime to run PHP code. This
> enables any language that supports WebAssembly (including C++, Rust, Go but
> also Python, PHP, Ruby) to run with mod_wasm and take advantage of the
> extra level of security and sandboxing. To learn more about mod_wasm you
> can check out the following resources:
> >
> >   *   An overview article
> for the original release.
> >   *   We presented mod_wasm at ApacheCon this year and here are the
> slides<
> https://apachecon.com/acna2022/slides/01_Gonz%c3%a1lez_mod-wasm_Bringing_WebAssembly.pdf>
> and the source code: https://github.com/vmware-labs/mod_wasm.
> >   *   CNCF Talk on mod_wasm showcasing how to run WordPress:
> https://www.youtube.com/watch?v=jXe8kulUscQ
> >
> >
> >
> > In terms of mod_wasm architecture, the module is split into two parts:
> >
> >   *   mod_wasm.so is the extension module for Apache and it’s written in
> C.
> >   *   An external dependency: libwasm_runtime.so, which is written in
> Rust and needs to be installed into the system.
> >
> >
> >
> > We modelled this after mod_tls, a module that is part of httpd and also
> has a Rust dependency.
> >
> > You can take a look at the architecture diagram and instructions on how
> to build the module here:
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> >
> >
> >
> > In terms of the actual contribution, please find a patch attached. We
> tried to follow all existing conventions in terms of autoconf/automake,
> providing module documentation, etc. Please let us know anything that you
> see missing or could be improved. In particular, we do not know yet if it
> is better to keep the Rust code separate, as an external dependency (like
> mod_tls does) or in the Apache source code repository.
> >
> >
> >
> > In summary, we believe mod_wasm is a worthy addition to httpd and it
> will allow us to catch up to some of the other web servers already
> supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim
> Jagielski and Jean-Frederic Clere to submit it for contribution upstream
> and we are looking forward to your feedback.
> >
> >
> >
> > Cheers!
> >
> > Jesús
> >
> >
> >
> >
> >
>


Re: mod_wasm: Contributing Upstream to Apache

2023-05-30 Thread José Carlos Chávez
I think not making WASM a first class concern in a proxy or server is missing 
out, more so in those platforms where extensibility isn't trivial. Apache will 
remain running in current setups but having limited extensibility is something 
concerning these days as systems are getting more and more complex. Writing an 
apache module isn't something you do every day and it probably takes quite some 
time, writing a wasm app following certain ABI is something you can do in 
minutes, hence supporting mod_wasm as a first class concern could be a good 
point in the sustainability of an ecosystem when it comes to moving forward out 
of the status quo.

On 2022/11/14 06:37:34 Jesús González wrote:
> Hi everyone,
> 
> 
> 
> I’m Jesús González, and I am part of VMware’s Wasm Labs: 
> wasmlabs.dev, a group focused on creating open source 
> tools for WebAssembly.
> 
> We have created mod_wasm, an Apache module for running WebAssembly binaries 
> inside httpd, and we would like to contribute it upstream. Please see below 
> for more details. We would love to get your feedback and understand what 
> improvements would be needed (if any) before it could be considered for 
> contribution to the project.
> 
> 
> 
> 
> 
> The details:
> 
> 
> 
> WebAssembly (Wasm) is a new binary instruction 
> format that is open, portable, efficient, secure, and polyglot. It originated 
> in the browser but is increasingly used in server applications, in particular 
> NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: 
> https://apisix.apache.org/docs/apisix/wasm/).
> 
> 
> 
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is 
> similar to how mod_php embeds a PHP runtime to run PHP code. This enables any 
> language that supports WebAssembly (including C++, Rust, Go but also Python, 
> PHP, Ruby) to run with mod_wasm and take advantage of the extra level of 
> security and sandboxing. To learn more about mod_wasm you can check out the 
> following resources:
> 
>   *   An overview article for 
> the original release.
>   *   We presented mod_wasm at ApacheCon this year and here are the 
> slides
>  and the source code: https://github.com/vmware-labs/mod_wasm.
>   *   CNCF Talk on mod_wasm showcasing how to run WordPress: 
> https://www.youtube.com/watch?v=jXe8kulUscQ
> 
> 
> 
> In terms of mod_wasm architecture, the module is split into two parts:
> 
>   *   mod_wasm.so is the extension module for Apache and it’s written in C.
>   *   An external dependency: libwasm_runtime.so, which is written in Rust 
> and needs to be installed into the system.
> 
> 
> 
> We modelled this after mod_tls, a module that is part of httpd and also has a 
> Rust dependency.
> 
> You can take a look at the architecture diagram and instructions on how to 
> build the module here: 
> https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm
> 
> 
> 
> In terms of the actual contribution, please find a patch attached. We tried 
> to follow all existing conventions in terms of autoconf/automake, providing 
> module documentation, etc. Please let us know anything that you see missing 
> or could be improved. In particular, we do not know yet if it is better to 
> keep the Rust code separate, as an external dependency (like mod_tls does) or 
> in the Apache source code repository.
> 
> 
> 
> In summary, we believe mod_wasm is a worthy addition to httpd and it will 
> allow us to catch up to some of the other web servers already supporting 
> Wasm, like NGINX. We were encouraged by Rich Bowen, Jim Jagielski and 
> Jean-Frederic Clere to submit it for contribution upstream and we are looking 
> forward to your feedback.
> 
> 
> 
> Cheers!
> 
> Jesús
> 
> 
> 
> 
> 


Re: mod_wasm: Contributing Upstream to Apache

2023-05-02 Thread Jesús González
Hola!

We just released a mod_wasm security update (v0.11.2) to address a recent CVE 
(low security). More details in the 
changelog.

Cheers,
Jesús



Re: mod_wasm: Contributing Upstream to Apache

2023-04-11 Thread Jesús González
Hola!



We have released recent versions of mod_wasm allowing Wasm modules to return 
any output type via stdout, including binaries with non UTF-8 bytes sequences 
or \0 NULL terminators in the middle, among other fixes (see 
CHANGELOG for 
details).


These new versions allowed us to run new fully functional and unmodified 
applications (such as Drupal) in a safe WebAssembly environment. We will 
release a demo soon and a post with all the details.



We believe mod_wasm is getting ready for a v1.0.0 release. So, we really would 
like to get feedback from the HTTPD committers here. Still our plan is 
contributing this module upstream and helping to maintain it.



Cheers!

Jesús



Re: mod_wasm: Contributing Upstream to Apache

2023-03-10 Thread Jesús González
Great! Thanks Steffen.


Re: mod_wasm: Contributing Upstream to Apache

2023-03-10 Thread SteffenAL


Done,  version 0.10.3 available on the VS17 download page.

Cheers, Steffen


On Thursday 09/03/2023 at 16:34, Jesús González  wrote:



Hola!

We just released a mod_wasm security update (v0.10.3) to address two 
recently disclosed CVEs (one critical) of Wasmtime, the WebAssembly 
runtime mod_wasm uses.


Further details can be found in this article and in the mod_wasm 
changelog.


Let us know if you find any issues.

Cheers!
Jesús




Re: mod_wasm: Contributing Upstream to Apache

2023-03-09 Thread Jesús González
Hola!

We just released a mod_wasm security update 
(v0.10.3) to 
address two recently disclosed CVEs (one critical) of Wasmtime, the WebAssembly 
runtime mod_wasm uses.

Further details can be found in this 
article and in 
the mod_wasm 
changelog.

Let us know if you find any issues.

Cheers!
Jesús


Re: mod_wasm: Contributing Upstream to Apache

2023-02-01 Thread Jesús González
Yes, the usage of Wasm for filters makes a lot of sense. This is why I 
previously mentioned the Envoy’s proxy-wasm 
spec, which is essentially an ABI 
specification for running WebAssembly in proxies. Beyond Envoy, you can find 
similar approaches in 
Nginx
 and in 
APISIX. 
One of our long term goals is to implement this specification for Apache itself.

mod_wasm’s initial goal is to allow running unmodified apps under WebAssembly 
in Apache (i.e.: WordPress, Drupal, etc.). Having said that, it is also a great 
fit to expose the internal Apache APIs, enabling safely building Apache modules 
using ANY language, not just filters but any functionality. Basically, a lot of 
the functionality you need to use mod_lua and mod_perl (or having to write your 
own C module) but language independence and with other benefits inherited by 
running Wasm code: sandboxing security, running at almost native, etc.


Re: Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Joe Schaefer
Part of the really cool things you'd like to have as an app-server author
that knows the APR/APU/HTTPd runtime are subrequests, including the
portions that interact with the filter API.
I'm always writing home-grown app-specific SSI-ish filters via mod_perl to
process application pages as event-driven streams.  It will be interesting
to compare mod_wasm with mod_perl2
in terms of security / sandbox models and weigh them against other
nonfunctional features (memory, latency, CPU, etc).


On Fri, Jan 27, 2023 at 12:28 PM Jesús González  wrote:

> Hi Eric,
>
> Thanks for the feedback. Though Wasm is relatively new it is being adopted
> by other HTTP-related projects, like NGINX and Envoy proxy and even ASF
> projects like APISIX. We want to contribute upstream to bring some of these
> new features to the Apache web server, similarly to how we are working to
> contribute our changes to other projects upstream (SQLite, PHP). We plan to
> continue to development and maintenance regardless of future VMware
> involvement. In fact, the reason we started this project was because our
> manager Daniel Lopez was an early ASF member and he looks at this as a way
> to contribute back to the community. We are initially targeting support for
> regular web apps such as WordPress, but we plan for mod_wasm to enable
> safely extending Apache's own functionality, providing access to the module
> API from Wasm code.
>
> On 2023/01/24 20:36:44 Eric Covener wrote:
> > > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
> >
> > As a pessimistic PMC member not caring about WASM or these languages,
> > I worry that marrying the lifecycle together is not advantageous for
> > either side. Of course I worry about being stuck with the pieces when
> > employer interest wanes or after turnover. It does not seem like it's
> > strictly necessary to be part of the server distribution (there are
> > many examples of successful out-of-tree modules).
> >
> > However the above is no veto.
> >
>


Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Joe Schaefer
Looking over the WASM Roadmap, it appears that they have a plan for
multithreading within a single target language.  That would allow you to
fully support every silly GIL-addled language runtime out there, which
would be very compelling.

On Fri, Jan 27, 2023 at 1:33 PM Joe Schaefer  wrote:

> A native interface outside of CGI compat for apreq would be a killer new
> feature, because it really finishes our vision for apreq as the
> one-HTML-spec-parser for all native apps, regardless of language choice. Of
> course this would be a new opt-in feature for target languages to take
> advantage of, but it will really set apart the speed freaks in your
> userbase.
>
>


Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Joe Schaefer
A native interface outside of CGI compat for apreq would be a killer new
feature, because it really finishes our vision for apreq as the
one-HTML-spec-parser for all native apps, regardless of language choice. Of
course this would be a new opt-in feature for target languages to take
advantage of, but it will really set apart the speed freaks in your
userbase.


Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Jesús González
Thanks Joe. You are correct, this initial implementation is the simplest one to 
get it off the ground. We plan to continue development and add the streaming 
functionality, which we know we will need for things like large PDF file 
generation or support for Proxy-Wasm.

Yes, isolating language runtimes (PHP, Python, ...) per thread is a cool 
feature that enables new possibilities like simultaneously supporting multiple 
versions of PHP as well as better multi-tenancy (you will be able to keep 
user's code and assets separate from each other using Wasm built-in isolation 
mechanism).

Regarding apreq, right now we have not had a need to use it as we pass most of 
the headers and body to the runtimes themselves as the language runtimes code 
for handling requests, etc. takes care of it as part of the CGI implementation, 
etc. As we look to add different functionality (i.e. extending Apache itself) 
we will probably provide access to it from Wasm.


De: Joe Schaefer 
Responder a: "dev@httpd.apache.org" 
Fecha: jueves, 26 de enero de 2023, 5:17
Para: "dev@httpd.apache.org" 
Asunto: Re: mod_wasm: Contributing Upstream to Apache

Still, the idea is wicked cool if mod_wasm really can isolate the Python, PHP, 
etc targets onto individual POSIX threads.

Very exciting stuff for HTTP/2 Webapps.


RE: Re: mod_wasm: Contributing Upstream to Apache

2023-01-27 Thread Jesús González
Hi Eric,

Thanks for the feedback. Though Wasm is relatively new it is being adopted by 
other HTTP-related projects, like NGINX and Envoy proxy and even ASF projects 
like APISIX. We want to contribute upstream to bring some of these new features 
to the Apache web server, similarly to how we are working to contribute our 
changes to other projects upstream (SQLite, PHP). We plan to continue to 
development and maintenance regardless of future VMware involvement. In fact, 
the reason we started this project was because our manager Daniel Lopez was an 
early ASF member and he looks at this as a way to contribute back to the 
community. We are initially targeting support for regular web apps such as 
WordPress, but we plan for mod_wasm to enable safely extending Apache's own 
functionality, providing access to the module API from Wasm code.

On 2023/01/24 20:36:44 Eric Covener wrote:
> > We are still very interested in contributing this module upstream and 
> > helping to maintain it. Please, let us know what improvements or changes 
> > would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover. It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>


Re: mod_wasm: Contributing Upstream to Apache

2023-01-25 Thread Joe Schaefer
Still, the idea is wicked cool if mod_wasm really can isolate the Python,
PHP, etc targets onto individual POSIX threads.

Very exciting stuff for HTTP/2 Webapps.

On Wed, Jan 25, 2023 at 4:31 AM Joe Schaefer  wrote:

> Looked at the PR- the IO is pretty primitive (no streaming anywhere).
> Probably not fatal for Webapps, but it could use some better relations with
> the filter stack and bucket brigades.
>
> Joe Schaefer, Ph.D
> 
> +1 (954) 253-3732
> SunStar Systems, Inc.
> *Orion - The Enterprise Jamstack Wiki*
>
> --
> *From:* Joe Schaefer 
> *Sent:* Tuesday, January 24, 2023 4:06:13 PM
> *To:* dev@httpd.apache.org 
> *Subject:* Re: mod_wasm: Contributing Upstream to Apache
>
> Would be great to marry it to apreq, too.
>
> On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer  wrote:
>
> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:
>
> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover.  It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>
> --
Joe Schaefer, Ph.D.
<https://sunstarsys.com/orion/features>
Orion - The Enterprise Jamstack Wiki <https://sunstarsys.com/orion/features>

954.253.3732 


Re: mod_wasm: Contributing Upstream to Apache

2023-01-25 Thread Joe Schaefer
Looked at the PR- the IO is pretty primitive (no streaming anywhere).  Probably 
not fatal for Webapps, but it could use some better relations with the filter 
stack and bucket brigades.

Joe Schaefer, Ph.D

+1 (954) 253-3732
SunStar Systems, Inc.
Orion - The Enterprise Jamstack Wiki


From: Joe Schaefer 
Sent: Tuesday, January 24, 2023 4:06:13 PM
To: dev@httpd.apache.org 
Subject: Re: mod_wasm: Contributing Upstream to Apache

Would be great to marry it to apreq, too.

On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer 
mailto:j...@sunstarsys.com>> wrote:
It is impossible to run mod_h2 without it or similar.

On Tue, Jan 24, 2023 at 3:37 PM Eric Covener 
mailto:cove...@gmail.com>> wrote:
> We are still very interested in contributing this module upstream and helping 
> to maintain it. Please, let us know what improvements or changes would be 
> needed for it to be considered ready for inclusion.

As a pessimistic PMC member not caring about WASM or these languages,
I worry that marrying the lifecycle together is not advantageous for
either side. Of course I worry about being stuck with the pieces when
employer interest wanes or after turnover.  It does not seem like it's
strictly necessary to be part of the server distribution (there are
many examples of successful out-of-tree modules).

However the above is no veto.


Re: mod_wasm: Contributing Upstream to Apache

2023-01-24 Thread Joe Schaefer
Would be great to marry it to apreq, too.

On Tue, Jan 24, 2023 at 4:04 PM Joe Schaefer  wrote:

> It is impossible to run mod_h2 without it or similar.
>
> On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:
>
>> > We are still very interested in contributing this module upstream and
>> helping to maintain it. Please, let us know what improvements or changes
>> would be needed for it to be considered ready for inclusion.
>>
>> As a pessimistic PMC member not caring about WASM or these languages,
>> I worry that marrying the lifecycle together is not advantageous for
>> either side. Of course I worry about being stuck with the pieces when
>> employer interest wanes or after turnover.  It does not seem like it's
>> strictly necessary to be part of the server distribution (there are
>> many examples of successful out-of-tree modules).
>>
>> However the above is no veto.
>>
>


Re: mod_wasm: Contributing Upstream to Apache

2023-01-24 Thread Joe Schaefer
It is impossible to run mod_h2 without it or similar.

On Tue, Jan 24, 2023 at 3:37 PM Eric Covener  wrote:

> > We are still very interested in contributing this module upstream and
> helping to maintain it. Please, let us know what improvements or changes
> would be needed for it to be considered ready for inclusion.
>
> As a pessimistic PMC member not caring about WASM or these languages,
> I worry that marrying the lifecycle together is not advantageous for
> either side. Of course I worry about being stuck with the pieces when
> employer interest wanes or after turnover.  It does not seem like it's
> strictly necessary to be part of the server distribution (there are
> many examples of successful out-of-tree modules).
>
> However the above is no veto.
>


Re: mod_wasm: Contributing Upstream to Apache

2023-01-24 Thread Eric Covener
> We are still very interested in contributing this module upstream and helping 
> to maintain it. Please, let us know what improvements or changes would be 
> needed for it to be considered ready for inclusion.

As a pessimistic PMC member not caring about WASM or these languages,
I worry that marrying the lifecycle together is not advantageous for
either side. Of course I worry about being stuck with the pieces when
employer interest wanes or after turnover.  It does not seem like it's
strictly necessary to be part of the server distribution (there are
many examples of successful out-of-tree modules).

However the above is no veto.


Re: mod_wasm: Contributing Upstream to Apache

2023-01-24 Thread Jesús González
Hola!

I wanted to update you on our progress since we have recently published new 
WebAssembly builds for several language runtimes, including:
- PHP 8.1.11 and 8.2.0
- Python 3.11.1
- Ruby 3.2.0

With the inclusion of multi-module support in the mod_wasm v0.10.0 release, 
Apache can now serve different applications written in these languages using 
just mod_wasm, all under the WebAssembly security model.

We also opened a pull request (PR#335) about a month ago that includes the 
source code, documentation, and scripting needed to build mod_wasm as an 
experimental module, as well as a test to build it on Travis CI.

We are still very interested in contributing this module upstream and helping 
to maintain it. Please, let us know what improvements or changes would be 
needed for it to be considered ready for inclusion.

Thanks!




Re: mod_wasm: Contributing Upstream to Apache

2023-01-17 Thread Jesús González
Hola!

Did anyone have the chance to take a look to the latest PR?
It would be great to receive any additional feedback with the upstream 
contribution in mind.

We are making great progress in our end, now focused on porting more PHP apps 
for mod_wasm, and support for new language runtimes such as Python and Ruby.

Thanks!

















FW: mod_wasm: Contributing Upstream to Apache

2022-12-20 Thread Jesús González
Hi everyone,

A couple of good news.

First, now mod_wasm and its dependency wasm_runtime are successfully built as 
part of a new test in Travis CI: 
https://app.travis-ci.com/github/apache/httpd/jobs/591640483 
The changes have been added to the open PR #335: 
https://github.com/apache/httpd/pull/335

Secondly, we built a mod_wasm.so and a wasm_runtime.dll versions for Windows 
and tested them successfully with XAMMP.
We have been collaborating with Apache Lounge folks and now we have a first 
"mod_wasm for Windows" package: 
https://www.apachelounge.com/download/VS17/modules/mod_wasm-0.10.1-win64-VS17.zip

Looking forward to your feedback and next steps for contribution.

Have a Merry Christmas and Happy New Year!
Jesús









Re: mod_wasm: Contributing Upstream to Apache

2022-12-13 Thread Jesús González
Thanks, Ruediger!

mod_wasm code can be reviewed now on the PR: 
https://github.com/apache/httpd/pull/335
I will work on adding a Travis CI test for mod_wasm.

Cheers,
Jesús

El 13/12/22, 20:45, "Ruediger Pluem" mailto:rpl...@apache.org>> escribió:


!! External Email


On 12/13/22 7:58 PM, Jesús González wrote:
> Thank Jean-Frederic for your feedback!
>
> Regarding reviewing from the diff, I agree that a PR to GitHub will ease the 
> review process.
> I'm afraid I don't have enough permission to do it. Who/where can I ask for 
> it?


You don't need special permissions. Just create a fork of 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fhttpddata=05%7C01%7Cjesusgm%40vmware.com%7C47055f4dc74c4b83020f08dadd429a24%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638065575374911445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8LaYxIvquVrH%2FrssQ%2Fl0vCE4T0hr0dRhh1quVybdSIY%3Dreserved=0
 

 with your github account.
Branch trunk to your feature branch in this fork. Commit mod_wasm to it and 
create a PR against 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fhttpddata=05%7C01%7Cjesusgm%40vmware.com%7C47055f4dc74c4b83020f08dadd429a24%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638065575374911445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=8LaYxIvquVrH%2FrssQ%2Fl0vCE4T0hr0dRhh1quVybdSIY%3Dreserved=0
 



Regards


Rüdiger




!! External Email: This email originated from outside of the organization. Do 
not click links or open attachments unless you recognize the sender.





Re: mod_wasm: Contributing Upstream to Apache

2022-12-13 Thread Ruediger Pluem



On 12/13/22 7:58 PM, Jesús González wrote:
> Thank Jean-Frederic for your feedback!
> 
> Regarding reviewing from the diff, I agree that a PR to GitHub will ease the 
> review process.
> I'm afraid I don't have enough permission to do it. Who/where can I ask for 
> it?

You don't need special permissions. Just create a fork of 
https://github.com/apache/httpd with your github account.
Branch trunk to your feature branch in this fork. Commit mod_wasm to it and 
create a PR against https://github.com/apache/httpd

Regards

Rüdiger



Re: mod_wasm: Contributing Upstream to Apache

2022-12-13 Thread Jesús González
Thank Jean-Frederic for your feedback!

Regarding reviewing from the diff, I agree that a PR to GitHub will ease the 
review process.
I'm afraid I don't have enough permission to do it. Who/where can I ask for it?

On the issue with wasm_return_const_char_ownership(), that's probably because 
we renamed the function name in the latest v0.10.0 for consistency.
Rebuilding everything (including the Rust library) should make that work.

With respect to the headers, in the update from yesterday both mod_wasm.h and 
mod_wasm.c now include the extended the Apache-2.0 license text as the other 
modules.

Finally, yes our goal is to donate the module code and help to maintain it! __

Jesús

El 13/12/22, 18:57, "jean-frederic clere" mailto:jfcl...@gmail.com>> escribió:


!! External Email


On 11/14/22 07:37, Jesús González wrote:
> Hi everyone,
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev
> 
>  
> ,
>  a group focused on creating open source tools
> for WebAssembly.
>
> We have created mod_wasm, an Apachemodule for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream.
> Please see below for more details. We would love to get your feedback
> and understand what improvements would be needed (if any) before it
> could be considered for contribution to the project.
>
> The details:
>
> WebAssembly 
> 
>  
> (Wasm)
>  is a new binary instruction
> format that is open, portable, efficient, secure, and polyglot. It
> originated in the browser but is increasingly used in server
> applications, in particular NGINX, Apache APISIX, Istio provide
> Wasm-based plugin support (i.e.:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapisix.apache.org%2Fdocs%2Fapisix%2Fwasm%2Fdata=05%7C01%7Cjesusgm%40vmware.com%7Cb9252a6ca5404ddfd20008dadd337411%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C638065510315707067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=iJHoUOiV%2B%2FgD3VzOqhugsOnFrliTCQQChWQ%2Bdj5APwM%3Dreserved=0
>  
> 
> 
>  
> ).
>
> mod_wasm is a way to run WebAssembly 

Re: mod_wasm: Contributing Upstream to Apache

2022-12-13 Thread jean-frederic clere

On 11/14/22 07:37, Jesús González wrote:

Hi everyone,

I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev 
, a group focused on creating open source tools 
for WebAssembly.


We have created mod_wasm, an Apachemodule for running WebAssembly 
binaries inside httpd, and we would like to contribute it upstream. 
Please see below for more details. We would love to get your feedback 
and understand what improvements would be needed (if any) before it 
could be considered for contribution to the project.


The details:

WebAssembly (Wasm) is a new binary instruction 
format that is open, portable, efficient, secure, and polyglot. It 
originated in the browser but is increasingly used in server 
applications, in particular NGINX, Apache APISIX, Istio provide 
Wasm-based plugin support (i.e.: 
https://apisix.apache.org/docs/apisix/wasm/ 
).


mod_wasm is a way to run WebAssembly modules inside Apache Server. This 
is similar to how mod_php embeds a PHP runtime to run PHP code. This 
enables any language that supports WebAssembly (including C++, Rust, Go 
but also Python, PHP, Ruby) to run with mod_wasm and take advantage of 
the extra level of security and sandboxing. To learn more about mod_wasm 
you can check out the following resources:


  * An overviewarticle
for the original
release.
  * We presented mod_wasm at ApacheCon this year and here are theslides

and
 the source code:https://github.com/vmware-labs/mod_wasm 
.
  * CNCF Talk on mod_wasm showcasing how to run
WordPress:https://www.youtube.com/watch?v=jXe8kulUscQ


In terms of mod_wasm architecture, the module is split into two parts:

  * /mod_wasm.so/is the extension module for Apache and it’s written in C.
  * An external dependency:/libwasm_runtime.so/, which is written in
Rust and needs to be installed into the system.

We modelled this after mod_tls, a module that is part of httpd and also 
has a Rust dependency.


You can take a look at the architecture diagram and instructions on how 
to build the module 
here:https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm 



In terms of the actual contribution, please find a patch attached. We 
tried to follow all existing conventions in terms of autoconf/automake, 
providing module documentation, etc. Please let us know anything that 
you see missing or could be improved. In particular, we do not know yet 
if it is better to keep the Rust code separate, as an external 
dependency (like mod_tls does) or in the Apache source code repository.


In summary, we believe mod_wasm is a worthy addition to httpd and it 
will allow us to catch up to some of the other web servers already 
supporting Wasm, like NGINX. We were encouraged by Rich Bowen, Jim 
Jagielski and Jean-Frederic Clere to submit it for contribution upstream 
and we are looking forward to your feedback.


Today I have send some time of mod_wasm, basically I have build the 
module and the runtime and run the hello demo. Using 
https://github.com/vmware-labs/mod_wasm.git (main)


Reviewing that from a diff is hard, probably probably a PR again httpd 
(https://github.com/apache/httpd/tree/trunk for example) would more easy 
to review.


When trying to run the hello I noted that requires a big runtime 
(basically I had unresolved wasm_return_const_char_ownership() which 
comes from a rust file).


I also noted that the headers in the c and h file needs to updated.

And to clarify your goal is to donate the modules code and help to 
maintain it, correct?





Cheers!

Jesús



--
Cheers

Jean-Frederic



Re: mod_wasm: Contributing Upstream to Apache

2022-12-12 Thread Jesús González
Thanks for your feedback, Christophe!

We have addressed all these different issues in our repo:
- All logging is now properly route to `ap_log_error()`, `ap_log_perror()` and 
`ap_log_rerror()`.
- Also now using APLOG_MARK, and all errors marked as APLOG_ERR.
- Removed unused code in create_dir_config().
- Apache-2.0 extended license headers.
- Only C89 comments (/* */), double new lines removed.
- Other minor tweaks.

An updated patch is attached. 
It might also be interesting to submit a PR to the mirror repo at GitHub to 
ease the review, but I think I'd need proper permissions. Just let me know what 
you prefer.

Our goal is still to donate the code to the ASF and help to maintain it.

Cheers,
Jesús


El 9/12/22, 19:39, "Christophe JAILLET" mailto:christophe.jail...@wanadoo.fr>> escribió:


!! External Email


Le 28/11/2022 à 19:17, Jesús González a écrit :
> Hi everyone,
>
> Following up on our email about contributing mod_wasm, we have continued
> to make progress on our side and just released mod_wasm v0.10.0.
>


Hi,


just a few nits to clean code and help reviews:


- No need to send html files, it will be generated by the framework
- I don't see the need for trace_nocontext(). Also have a look at
APLOG_MARK and its usages.
- APLOG_NOTICE looks too high for trace logging. APLOG_DEBUG?
- At the end of create_dir_config(), 'note' and the corresponding
apr_psprintf() are useless or a debugging logging call is missing
- Please use only C89 comments (/* */) - try to configure with
--enable-maintainer-mode
- some double new lines could be saved


CJ





mod_wasm_v0.10.1.diff
Description: mod_wasm_v0.10.1.diff


Re: mod_wasm: Contributing Upstream to Apache

2022-12-09 Thread Christophe JAILLET

Le 28/11/2022 à 19:17, Jesús González a écrit :

Hi everyone,

Following up on our email about contributing mod_wasm, we have continued 
to make progress on our side and just released mod_wasm v0.10.0.




Hi,

just a few nits to clean code and help reviews:

   - No need to send html files, it will be generated by the framework
   - I don't see the need for trace_nocontext(). Also have a look at 
APLOG_MARK and its usages.

   - APLOG_NOTICE looks too high for trace logging. APLOG_DEBUG?
   - At the end of create_dir_config(), 'note' and the corresponding 
apr_psprintf() are useless or a debugging logging call is missing
   - Please use only C89 comments (/* */) - try to configure with 
--enable-maintainer-mode

   - some double new lines could be saved

CJ


In this version, among other improvements, we introduce two major features:

  * #1: Wasm multi-module support
  * #2: Shared Wasm modules

In #1, you can now specify different Wasm modules to be used in 
different routes. For instance, now it’s possible with one-single Apache 
instance to load simultaneously the Wasm builds for the PHP 
<https://github.com/vmware-labs/webassembly-language-runtimes/releases>and Python <https://github.com/tiran/cpython-wasm-test/releases>interpreters (and any other languages that compile to Wasm now or in the future).


And in #2, you can now specify different per-route configurations to the 
same Wasm module. 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, you can have a more flexible configuration such as:



     SetHandler wasm-handler

     WasmModule /var/www/modules/php7.4.32.wasm

     WasmDir    /tmp

     …





     SetHandler wasm-handler

     WasmModule /var/www/modules/python3.11.wasm

     WasmArg    /var/www/python-app/app.py

     …





     SetHandler wasm-handler

     WasmModule /var/www/modules/python3.11.wasm

     WasmArg    /var/www/python-app2/app2.py

     …



We have run some simple, preliminary stress tests using ApacheBench and 
mod_wasm performs great in both MPM event and MPM worker modes.


Hope you can find some time to try mod_wasm and provide feedback. Let us 
know if you have questions or suggestions.


Jesús

PS: Updated patch attached.

*De: *Jesús González 
*Responder a: *"dev@httpd.apache.org" 
*Fecha: *lunes, 14 de noviembre de 2022, 7:38
*Para: *"dev@httpd.apache.org" 
*CC: *Daniel Lopez Ridruejo 
*Asunto: *mod_wasm: Contributing Upstream to Apache

Hi everyone,

I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwasmlabs.dev%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hQnzxjyjL4RPU5GK%2FUz9N6AMlsTsJlxX%2BQSkn2E8XzI%3D=0>, a group focused on creating open source tools for WebAssembly.


We have created mod_wasm, an Apachemodule for running WebAssembly 
binaries inside httpd, and we would like to contribute it upstream. 
Please see below for more details. We would love to get your feedback 
and understand what improvements would be needed (if any) before it 
could be considered for contribution to the project.


The details:

WebAssembly 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebassembly.org%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=MsBjIpsju0J9AHkCXLy2%2BY83MIaLzhywcjIIPOAcKkg%3D=0>(Wasm) is a new binary instruction format that is open, portable, efficient, secure, and polyglot. It originated in the browser but is increasingly used in server applications, in particular NGINX, Apache APISIX, Istio provide Wasm-based plugin support (i.e.: https://apisix.apache.org/docs/apisix/wasm/ <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapisix.apache.org%2Fdocs%2Fapisix%2Fwasm%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jXuPc0uRObYzq6O98T51ypWizrmus%2FdSGwGk6Gi40VQ%3D=0>).


mod_wasm is a way to run WebAssembly modules inside Apache Server. This 
is similar to how mod_php embeds a PHP runtime to run PHP code. This 
enables any language that supports WebAssembly (including C++, Rust, Go 
but also Python, PHP, Ruby) to run with mod_wasm and take advantage of 
the extra level of security and sandboxing. To learn more about mod_wasm 
you can check out the following resources:


  * An overviewarticle

<https://na

Re: mod_wasm: Contributing Upstream to Apache

2022-12-07 Thread Jesús González
Hi everyone,



We have just posted a new 
article 
about mod_wasm v0.10.0 and published a new 
container
 to try different mod_wasm demos in two simple steps:



  1.  Run the container:

docker run -p 8080:8080 ghcr.io/vmware-labs/httpd-mod-wasm:latest



  1.  Open browser at:
 *   http://localhost:8080/wordpress for a WordPress demo with PHP 7.3.33.
 *   http://localhost:8080/http-request-viewer for a HTTP Request Viewer 
demo with Python 3.11.



Hope this helps to visualize the ability of supporting different language 
runtimes (present and future ones!) in a secure way with one single module.



Looking forward to your feedback.

Jesús


Re: mod_wasm: Contributing Upstream to Apache

2022-11-28 Thread Joe Schaefer
Cool stuff!

On Mon, Nov 28, 2022 at 1:18 PM Jesús González  wrote:

> Hi everyone,
>
>
>
> Following up on our email about contributing mod_wasm, we have continued
> to make progress on our side and just released mod_wasm v0.10.0.
>
>
>
> In this version, among other improvements, we introduce two major features:
>
>- #1: Wasm multi-module support
>- #2: Shared Wasm modules
>
>
>
> In #1, you can now specify different Wasm modules to be used in different
> routes. For instance, now it’s possible with one-single Apache instance to
> load simultaneously the Wasm builds for the PHP
> <https://github.com/vmware-labs/webassembly-language-runtimes/releases>
> and Python <https://github.com/tiran/cpython-wasm-test/releases>
> interpreters (and any other languages that compile to Wasm now or in the
> future).
>
>
>
> And in #2, you can now specify different per-route configurations to the
> same Wasm module. 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, you can have a more flexible configuration such
> as:
>
>
>
> 
>
> SetHandler wasm-handler
>
> WasmModule /var/www/modules/php7.4.32.wasm
>
> WasmDir/tmp
>
> …
>
> 
>
>
>
> 
>
> SetHandler wasm-handler
>
> WasmModule /var/www/modules/python3.11.wasm
>
> WasmArg/var/www/python-app/app.py
>
> …
>
> 
>
>
>
> 
>
> SetHandler wasm-handler
>
> WasmModule /var/www/modules/python3.11.wasm
>
> WasmArg/var/www/python-app2/app2.py
>
> …
>
> 
>
>
>
>
>
> We have run some simple, preliminary stress tests using ApacheBench and
> mod_wasm performs great in both MPM event and MPM worker modes.
>
>
>
> Hope you can find some time to try mod_wasm and provide feedback. Let us
> know if you have questions or suggestions.
>
> Jesús
>
>
>
> PS: Updated patch attached.
>
>
>
>
>
> *De: *Jesús González 
> *Responder a: *"dev@httpd.apache.org" 
> *Fecha: *lunes, 14 de noviembre de 2022, 7:38
> *Para: *"dev@httpd.apache.org" 
> *CC: *Daniel Lopez Ridruejo 
> *Asunto: *mod_wasm: Contributing Upstream to Apache
>
>
>
> Hi everyone,
>
>
>
> I’m Jesús González, and I am part of VMware’s Wasm Labs: wasmlabs.dev
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwasmlabs.dev%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hQnzxjyjL4RPU5GK%2FUz9N6AMlsTsJlxX%2BQSkn2E8XzI%3D=0>,
> a group focused on creating open source tools for WebAssembly.
>
> We have created mod_wasm, an Apache module for running WebAssembly
> binaries inside httpd, and we would like to contribute it upstream. Please
> see below for more details. We would love to get your feedback and
> understand what improvements would be needed (if any) before it could be
> considered for contribution to the project.
>
>
>
>
>
> The details:
>
>
>
> WebAssembly
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebassembly.org%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=MsBjIpsju0J9AHkCXLy2%2BY83MIaLzhywcjIIPOAcKkg%3D=0>
> (Wasm) is a new binary instruction format that is open, portable,
> efficient, secure, and polyglot. It originated in the browser but is
> increasingly used in server applications, in particular NGINX, Apache
> APISIX, Istio provide Wasm-based plugin support (i.e.:
> https://apisix.apache.org/docs/apisix/wasm/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapisix.apache.org%2Fdocs%2Fapisix%2Fwasm%2F=05%7C01%7Cjesusgm%40vmware.com%7C07586834510d4ffc0a5108dac60ac618%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638040046834229085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jXuPc0uRObYzq6O98T51ypWizrmus%2FdSGwGk6Gi40VQ%3D=0>
> ).
>
>
>
> mod_wasm is a way to run WebAssembly modules inside Apache Server. This is
> similar to how mod_php embeds a PHP runtime to run PHP code. This enables
> any language that supports WebAssembly (including C++, Rust, Go but also
> Python, PHP, Ruby) to run with mod_wasm and take advantage of the extra
> le

mod_wasm: Contributing Upstream to Apache

2022-11-13 Thread Jesús González
Hi everyone,



I’m Jesús González, and I am part of VMware’s Wasm Labs: 
wasmlabs.dev, a group focused on creating open source 
tools for WebAssembly.

We have created mod_wasm, an Apache module for running WebAssembly binaries 
inside httpd, and we would like to contribute it upstream. Please see below for 
more details. We would love to get your feedback and understand what 
improvements would be needed (if any) before it could be considered for 
contribution to the project.





The details:



WebAssembly (Wasm) is a new binary instruction format 
that is open, portable, efficient, secure, and polyglot. It originated in the 
browser but is increasingly used in server applications, in particular NGINX, 
Apache APISIX, Istio provide Wasm-based plugin support (i.e.: 
https://apisix.apache.org/docs/apisix/wasm/).



mod_wasm is a way to run WebAssembly modules inside Apache Server. This is 
similar to how mod_php embeds a PHP runtime to run PHP code. This enables any 
language that supports WebAssembly (including C++, Rust, Go but also Python, 
PHP, Ruby) to run with mod_wasm and take advantage of the extra level of 
security and sandboxing. To learn more about mod_wasm you can check out the 
following resources:

  *   An overview article for 
the original release.
  *   We presented mod_wasm at ApacheCon this year and here are the 
slides
 and the source code: https://github.com/vmware-labs/mod_wasm.
  *   CNCF Talk on mod_wasm showcasing how to run WordPress: 
https://www.youtube.com/watch?v=jXe8kulUscQ



In terms of mod_wasm architecture, the module is split into two parts:

  *   mod_wasm.so is the extension module for Apache and it’s written in C.
  *   An external dependency: libwasm_runtime.so, which is written in Rust and 
needs to be installed into the system.



We modelled this after mod_tls, a module that is part of httpd and also has a 
Rust dependency.

You can take a look at the architecture diagram and instructions on how to 
build the module here: 
https://github.com/vmware-labs/mod_wasm#%EF%B8%8F-building-mod_wasm



In terms of the actual contribution, please find a patch attached. We tried to 
follow all existing conventions in terms of autoconf/automake, providing module 
documentation, etc. Please let us know anything that you see missing or could 
be improved. In particular, we do not know yet if it is better to keep the Rust 
code separate, as an external dependency (like mod_tls does) or in the Apache 
source code repository.



In summary, we believe mod_wasm is a worthy addition to httpd and it will allow 
us to catch up to some of the other web servers already supporting Wasm, like 
NGINX. We were encouraged by Rich Bowen, Jim Jagielski and Jean-Frederic Clere 
to submit it for contribution upstream and we are looking forward to your 
feedback.



Cheers!

Jesús






mod_wasm.diff
Description: mod_wasm.diff