Re: mod_wasm: Contributing Upstream to Apache

[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

[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

[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: svn commit: r1910161 - in /httpd/httpd/trunk: changes-entries/ include/ modules/http/ test/modules/http2/

[Ruediger Pluem]

On 6/1/23 3:30 PM, Stefan Eissing via dev wrote:

>>> Modified: httpd/httpd/trunk/modules/http/http_request.c
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1910161&r1=1910160&r2=1910161&view=diff
>>> ==
>>> --- httpd/httpd/trunk/modules/http/http_request.c (original)
>>> +++ httpd/httpd/trunk/modules/http/http_request.c Thu Jun  1 12:21:03 2023
>>> @@ -84,38 +84,25 @@ static void ap_die_r(int type, request_r
>>> return;
>>> }
>>>
>>> -if (!ap_is_HTTP_VALID_RESPONSE(type)) {
>>> -ap_filter_t *next;
>>> -
>>> -/*
>>> - * Check if we still have the ap_http_header_filter in place. If
>>> - * this is the case we should not ignore the error here because
>>> - * it means that we have not sent any response at all and never
>>> - * will. This is bad. Sent an internal server error instead.
>>> - */
>>> -next = r->output_filters;
>>> -while (next && (next->frec != ap_http_header_filter_handle)) {
>>> -   next = next->next;
>>> -}
>>
>> Out of curiosity: You changed to using the flag instead as the above did not 
>> detect all cases correctly or because it is not
>> performance optimal?
> 
> It did not catch all cases any longer since the httpd header filter does not 
> remove itself any longer. This is a result of the RESPONSE buckets changes in 
> trunk. So when ap_die() was called during response body processing, it added 
> a 500 body content to the response.
> 
> Instead of fiddling here with filter chain expectations, I found it more sane 
> to keep the bit at request_rec. But it can be discussed if there is a better 
> choice.

I think the new approach is cleaner and less performance consuming. I was just 
curious about the motivation to do it.

Regards

Rüdiger

Re: svn commit: r1910161 - in /httpd/httpd/trunk: changes-entries/ include/ modules/http/ test/modules/http2/

[Stefan Eissing via dev]

> Am 01.06.2023 um 15:21 schrieb Ruediger Pluem :
> 
> 
> 
> On 6/1/23 2:21 PM, ic...@apache.org wrote:
>> Author: icing
>> Date: Thu Jun  1 12:21:03 2023
>> New Revision: 1910161
>> 
>> URL: http://svn.apache.org/viewvc?rev=1910161&view=rev
>> Log:
>>  *) core: add `final_resp_passed` flag to request_rec to allow
>> ap_die() to judge if it can send out a response. Bump mmn.
>> Enable test cases that check errors during response body to
>> appear as error on client side.
>> 
>> 
>> Added:
>>httpd/httpd/trunk/changes-entries/resp_passed.txt
>> Modified:
>>httpd/httpd/trunk/include/ap_mmn.h
>>httpd/httpd/trunk/include/httpd.h
>>httpd/httpd/trunk/modules/http/http_filters.c
>>httpd/httpd/trunk/modules/http/http_request.c
>>httpd/httpd/trunk/test/modules/http2/test_008_ranges.py
>>httpd/httpd/trunk/test/modules/http2/test_500_proxy.py
>>httpd/httpd/trunk/test/modules/http2/test_601_h2proxy_twisted.py
>> 
> 
> 
>> Modified: httpd/httpd/trunk/modules/http/http_filters.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1910161&r1=1910160&r2=1910161&view=diff
>> ==
>> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
>> +++ httpd/httpd/trunk/modules/http/http_filters.c Thu Jun  1 12:21:03 2023
>> @@ -1265,7 +1265,7 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
>> 
>> if (ctx->final_status && ctx->final_header_only) {
>> /* The final RESPONSE has already been sent or is in front of 
>> `bcontent`
>> - * in the brigade. For a header_only respsone, remove all content 
>> buckets
>> + * in the brigade. For a header_only respone, remove all content 
>> buckets
> 
> Now the typo is different :-)

Spelling error forever! \o/

> 
>>  * up to the first EOS. On seeing EOS, we remove ourself and are 
>> done.
>>  * NOTE that `header_only` responses never generate trailes.
>>  */
> 
>> Modified: httpd/httpd/trunk/modules/http/http_request.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1910161&r1=1910160&r2=1910161&view=diff
>> ==
>> --- httpd/httpd/trunk/modules/http/http_request.c (original)
>> +++ httpd/httpd/trunk/modules/http/http_request.c Thu Jun  1 12:21:03 2023
>> @@ -84,38 +84,25 @@ static void ap_die_r(int type, request_r
>> return;
>> }
>> 
>> -if (!ap_is_HTTP_VALID_RESPONSE(type)) {
>> -ap_filter_t *next;
>> -
>> -/*
>> - * Check if we still have the ap_http_header_filter in place. If
>> - * this is the case we should not ignore the error here because
>> - * it means that we have not sent any response at all and never
>> - * will. This is bad. Sent an internal server error instead.
>> - */
>> -next = r->output_filters;
>> -while (next && (next->frec != ap_http_header_filter_handle)) {
>> -   next = next->next;
>> -}
> 
> Out of curiosity: You changed to using the flag instead as the above did not 
> detect all cases correctly or because it is not
> performance optimal?

It did not catch all cases any longer since the httpd header filter does not 
remove itself any longer. This is a result of the RESPONSE buckets changes in 
trunk. So when ap_die() was called during response body processing, it added a 
500 body content to the response.

Instead of fiddling here with filter chain expectations, I found it more sane 
to keep the bit at request_rec. But it can be discussed if there is a better 
choice.

Cheers,
Stefan

> 
>> +/*
>> + * if we have already passed the final response down the
>> + * output filter chain, we cannot generate a second final
>> + * response here.
>> + */
>> +if (r->final_resp_passed) {
>> +return;
>> +}
>> 
>> -/*
>> - * If next != NULL then we left the while above because of
>> - * next->frec == ap_http_header_filter
>> - */
>> -if (next) {
>> -if (type != AP_FILTER_ERROR) {
>> -ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
>> -  "Invalid response status %i", type);
>> -}
>> -else {
>> -ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02831)
>> -  "Response from AP_FILTER_ERROR");
>> -}
>> -type = HTTP_INTERNAL_SERVER_ERROR;
>> +if (!ap_is_HTTP_VALID_RESPONSE(type)) {
>> +if (type != AP_FILTER_ERROR) {
>> +ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
>> +  "Invalid response status %i", type);
>> }
>> else {
>> -return;
>> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02831)
>> + 

Re: svn commit: r1910161 - in /httpd/httpd/trunk: changes-entries/ include/ modules/http/ test/modules/http2/

[Ruediger Pluem]

On 6/1/23 2:21 PM, ic...@apache.org wrote:
> Author: icing
> Date: Thu Jun  1 12:21:03 2023
> New Revision: 1910161
> 
> URL: http://svn.apache.org/viewvc?rev=1910161&view=rev
> Log:
>   *) core: add `final_resp_passed` flag to request_rec to allow
>  ap_die() to judge if it can send out a response. Bump mmn.
>  Enable test cases that check errors during response body to
>  appear as error on client side.
> 
> 
> Added:
> httpd/httpd/trunk/changes-entries/resp_passed.txt
> Modified:
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/include/httpd.h
> httpd/httpd/trunk/modules/http/http_filters.c
> httpd/httpd/trunk/modules/http/http_request.c
> httpd/httpd/trunk/test/modules/http2/test_008_ranges.py
> httpd/httpd/trunk/test/modules/http2/test_500_proxy.py
> httpd/httpd/trunk/test/modules/http2/test_601_h2proxy_twisted.py
> 


> Modified: httpd/httpd/trunk/modules/http/http_filters.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1910161&r1=1910160&r2=1910161&view=diff
> ==
> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> +++ httpd/httpd/trunk/modules/http/http_filters.c Thu Jun  1 12:21:03 2023
> @@ -1265,7 +1265,7 @@ AP_CORE_DECLARE_NONSTD(apr_status_t) ap_
>  
>  if (ctx->final_status && ctx->final_header_only) {
>  /* The final RESPONSE has already been sent or is in front of 
> `bcontent`
> - * in the brigade. For a header_only respsone, remove all content 
> buckets
> + * in the brigade. For a header_only respone, remove all content 
> buckets

Now the typo is different :-)

>   * up to the first EOS. On seeing EOS, we remove ourself and are 
> done.
>   * NOTE that `header_only` responses never generate trailes.
>   */

> Modified: httpd/httpd/trunk/modules/http/http_request.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_request.c?rev=1910161&r1=1910160&r2=1910161&view=diff
> ==
> --- httpd/httpd/trunk/modules/http/http_request.c (original)
> +++ httpd/httpd/trunk/modules/http/http_request.c Thu Jun  1 12:21:03 2023
> @@ -84,38 +84,25 @@ static void ap_die_r(int type, request_r
>  return;
>  }
>  
> -if (!ap_is_HTTP_VALID_RESPONSE(type)) {
> -ap_filter_t *next;
> -
> -/*
> - * Check if we still have the ap_http_header_filter in place. If
> - * this is the case we should not ignore the error here because
> - * it means that we have not sent any response at all and never
> - * will. This is bad. Sent an internal server error instead.
> - */
> -next = r->output_filters;
> -while (next && (next->frec != ap_http_header_filter_handle)) {
> -   next = next->next;
> -}

Out of curiosity: You changed to using the flag instead as the above did not 
detect all cases correctly or because it is not
performance optimal?

> +/*
> + * if we have already passed the final response down the
> + * output filter chain, we cannot generate a second final
> + * response here.
> + */
> +if (r->final_resp_passed) {
> +return;
> +}
>  
> -/*
> - * If next != NULL then we left the while above because of
> - * next->frec == ap_http_header_filter
> - */
> -if (next) {
> -if (type != AP_FILTER_ERROR) {
> -ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
> -  "Invalid response status %i", type);
> -}
> -else {
> -ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02831)
> -  "Response from AP_FILTER_ERROR");
> -}
> -type = HTTP_INTERNAL_SERVER_ERROR;
> +if (!ap_is_HTTP_VALID_RESPONSE(type)) {
> +if (type != AP_FILTER_ERROR) {
> +ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(01579)
> +  "Invalid response status %i", type);
>  }
>  else {
> -return;
> +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02831)
> +  "Response from AP_FILTER_ERROR");
>  }
> +type = HTTP_INTERNAL_SERVER_ERROR;
>  }
>  
>  /*
> 

Regards

Rüdiger