Re: mod_wasm: Contributing Upstream to Apache

[Jesús González]

Hola!

mod_wasm 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, 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
>
>

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Yann Ylavic]

On Mon, Jul 3, 2023 at 11:10 AM Ruediger Pluem  wrote:
>
>
>
> On 7/3/23 10:17 AM, Stefan Eissing via dev wrote:
> >
> >
> >> Am 30.06.2023 um 17:22 schrieb Stefan Eissing via dev 
> >> :
> >>
> >>
> >>
> >>> Am 30.06.2023 um 16:45 schrieb Ruediger Pluem :
> >>>
> >>>
> >>>
> >>> On 6/30/23 4:15 PM, Stefan Eissing via dev wrote:
> 
> 
> > Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
> >
> > On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  
> > wrote:
> >>
> >> On 6/30/23 11:08 AM, ic...@apache.org wrote:
> >>> Author: icing
> >>> Date: Fri Jun 30 09:08:23 2023
> >>> New Revision: 1910704
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
> >>> Log:
> >>> proxy: in proxy tunnels, use the smaller timeout value of
> >>> client and origin as timeout for polling the tunnel.
> >>>
> >>>
> >>> Modified:
> >>>  httpd/httpd/trunk/modules/proxy/proxy_util.c
> >>>
> >>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> >>> URL: 
> >>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
> >>> ==
> >>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> >>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 
> >>> 2023
> >>> @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
> >>>   apr_socket_timeout_get(tunnel->origin->pfd->desc.s, 
> >>> &origin_timeout);
> >>>   apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
> >>>
> >>> -/* Defaults to the biggest timeout of both connections */
> >>> -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
> >>> client_timeout)?
> >>> -  origin_timeout : client_timeout;
> >>> +/* Defaults to the smallest timeout of both connections */
> >>> +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
> >>> origin_timeout ?
> >>> +   client_timeout : origin_timeout);
> >>
> >> Why?
> >
> > We discussed this (quickly) with Stefan on
> > https://github.com/apache/httpd/pull/366, but hey the commit is here
> > for review finally :)
> >
> >> It was the other way round on purpose, e.g. if Timeout is set to 5 for 
> >> a small front end timeout and ProxyTimeout is set to
> >> e.g. 600 to keep Websockets open for 10 minutes.
> >
> > It seems to me that using Timeout (5s) here is a valid case too if
> > Timeout < ProxyTimeout (as in your example) is a way to limit how long
> > a client can consume httpd resources.
> > So maybe we should only use the backend timeout which is an easy(er)
> > way for the user to control this?
> 
>  So, the goal is to allow someone keeping the websocket open for longer
>  than we usually allow for HTTP requests, to set a long ProxyTimeout or
>  timeout parameter to ProxyPass.
> 
>  For HTTP/1.1 that would override the connection Timeout, since the tunnel
>  poll would only use the largest value.
> 
>  For HTTP/2 I have to check how that how to accomplish that. The working
>  there is different.
> >>>
> >>> Sorry for being a bit grumpy above, but this came out of the blue for me. 
> >>> It breaks an important use case for me and the use case
> >>> for the other way round was not clear to me. Maybe we can find a solution 
> >>> that addresses both use cases at best by default and
> >>> automatically. Any pointers for your use case such that I can have a look 
> >>> and be more constructive :-).
> >>>
> >>
> >> Thanks that you spoke up! I heard no grumpiness. ;)
> >
> > Ok, testing how things *REALLY* work here, I stumbled upon:
> >
> > mod_proxy_http.c:1570
> > /* Let proxy tunnel forward everything within this thread */
> > req->tunnel->timeout = req->idle_timeout;
> > status = ap_proxy_tunnel_run(req->tunnel);
> >
> > which overrides everything we discussed. So, how do we want this to work 
> > and who has the final say?
>
> Very good catch. If you look at
> https://github.com/apache/httpd/blob/cc0735d1cde406c8d15016e4b2afcebb4d11fc87/modules/proxy/mod_proxy_http.c#L2009-L2023
>
> then in the proxy case the backend timeout seems to win. Hence my crying was 
> wrong and in the http proxy case things still work as
> before. The above was for trunk. In case of 2.4.x we also override the 
> setting from ap_proxy_tunnel_create here:
> https://github.com/apache/httpd/blob/aefc30086aa71f24f77290deb88f949f36575c05/modules/proxy/mod_proxy_http.c#L1538-L1549
>  in the
> same fashion as we set it in ap_proxy_tunnel_create: The longest one wins.
>
> What is actually your use case to use the shortest one? The new WebSocket 
> over HTTP/2 feature? Do we get hit by the fact that on
> HTTP/2 we have multiple conn_recs

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Stefan Eissing via dev]

> Am 03.07.2023 um 11:09 schrieb Ruediger Pluem :
> 
> 
> 
> On 7/3/23 10:17 AM, Stefan Eissing via dev wrote:
>> 
>> 
>>> Am 30.06.2023 um 17:22 schrieb Stefan Eissing via dev 
>>> :
>>> 
>>> 
>>> 
 Am 30.06.2023 um 16:45 schrieb Ruediger Pluem :
 
 
 
 On 6/30/23 4:15 PM, Stefan Eissing via dev wrote:
> 
> 
>> Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
>> 
>> On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  wrote:
>>> 
>>> On 6/30/23 11:08 AM, ic...@apache.org wrote:
 Author: icing
 Date: Fri Jun 30 09:08:23 2023
 New Revision: 1910704
 
 URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
 Log:
 proxy: in proxy tunnels, use the smaller timeout value of
client and origin as timeout for polling the tunnel.
 
 
 Modified:
 httpd/httpd/trunk/modules/proxy/proxy_util.c
 
 Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
 ==
 --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
 +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 
 2023
 @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
  apr_socket_timeout_get(tunnel->origin->pfd->desc.s, &origin_timeout);
  apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
 
 -/* Defaults to the biggest timeout of both connections */
 -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
 client_timeout)?
 -  origin_timeout : client_timeout;
 +/* Defaults to the smallest timeout of both connections */
 +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
 origin_timeout ?
 +   client_timeout : origin_timeout);
>>> 
>>> Why?
>> 
>> We discussed this (quickly) with Stefan on
>> https://github.com/apache/httpd/pull/366, but hey the commit is here
>> for review finally :)
>> 
>>> It was the other way round on purpose, e.g. if Timeout is set to 5 for 
>>> a small front end timeout and ProxyTimeout is set to
>>> e.g. 600 to keep Websockets open for 10 minutes.
>> 
>> It seems to me that using Timeout (5s) here is a valid case too if
>> Timeout < ProxyTimeout (as in your example) is a way to limit how long
>> a client can consume httpd resources.
>> So maybe we should only use the backend timeout which is an easy(er)
>> way for the user to control this?
> 
> So, the goal is to allow someone keeping the websocket open for longer
> than we usually allow for HTTP requests, to set a long ProxyTimeout or
> timeout parameter to ProxyPass.
> 
> For HTTP/1.1 that would override the connection Timeout, since the tunnel
> poll would only use the largest value.
> 
> For HTTP/2 I have to check how that how to accomplish that. The working
> there is different.
 
 Sorry for being a bit grumpy above, but this came out of the blue for me. 
 It breaks an important use case for me and the use case
 for the other way round was not clear to me. Maybe we can find a solution 
 that addresses both use cases at best by default and
 automatically. Any pointers for your use case such that I can have a look 
 and be more constructive :-).
 
>>> 
>>> Thanks that you spoke up! I heard no grumpiness. ;)
>> 
>> Ok, testing how things *REALLY* work here, I stumbled upon:
>> 
>> mod_proxy_http.c:1570
>>/* Let proxy tunnel forward everything within this thread */
>>req->tunnel->timeout = req->idle_timeout;
>>status = ap_proxy_tunnel_run(req->tunnel);
>> 
>> which overrides everything we discussed. So, how do we want this to work and 
>> who has the final say?
> 
> Very good catch. If you look at
> https://github.com/apache/httpd/blob/cc0735d1cde406c8d15016e4b2afcebb4d11fc87/modules/proxy/mod_proxy_http.c#L2009-L2023
> 
> then in the proxy case the backend timeout seems to win. Hence my crying was 
> wrong and in the http proxy case things still work as
> before. The above was for trunk. In case of 2.4.x we also override the 
> setting from ap_proxy_tunnel_create here:
> https://github.com/apache/httpd/blob/aefc30086aa71f24f77290deb88f949f36575c05/modules/proxy/mod_proxy_http.c#L1538-L1549
>  in the
> same fashion as we set it in ap_proxy_tunnel_create: The longest one wins.
> 
> What is actually your use case to use the shortest one? The new WebSocket 
> over HTTP/2 feature? Do we get hit by the fact that on
> HTTP/2 we have multiple conn_recs / streams over one TCP connection?

No actual use case. I am just looking to make it work

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Ruediger Pluem]

On 7/3/23 10:17 AM, Stefan Eissing via dev wrote:
> 
> 
>> Am 30.06.2023 um 17:22 schrieb Stefan Eissing via dev :
>>
>>
>>
>>> Am 30.06.2023 um 16:45 schrieb Ruediger Pluem :
>>>
>>>
>>>
>>> On 6/30/23 4:15 PM, Stefan Eissing via dev wrote:


> Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
>
> On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  wrote:
>>
>> On 6/30/23 11:08 AM, ic...@apache.org wrote:
>>> Author: icing
>>> Date: Fri Jun 30 09:08:23 2023
>>> New Revision: 1910704
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
>>> Log:
>>> proxy: in proxy tunnels, use the smaller timeout value of
>>> client and origin as timeout for polling the tunnel.
>>>
>>>
>>> Modified:
>>>  httpd/httpd/trunk/modules/proxy/proxy_util.c
>>>
>>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
>>> ==
>>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 
>>> 2023
>>> @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
>>>   apr_socket_timeout_get(tunnel->origin->pfd->desc.s, &origin_timeout);
>>>   apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
>>>
>>> -/* Defaults to the biggest timeout of both connections */
>>> -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
>>> client_timeout)?
>>> -  origin_timeout : client_timeout;
>>> +/* Defaults to the smallest timeout of both connections */
>>> +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
>>> origin_timeout ?
>>> +   client_timeout : origin_timeout);
>>
>> Why?
>
> We discussed this (quickly) with Stefan on
> https://github.com/apache/httpd/pull/366, but hey the commit is here
> for review finally :)
>
>> It was the other way round on purpose, e.g. if Timeout is set to 5 for a 
>> small front end timeout and ProxyTimeout is set to
>> e.g. 600 to keep Websockets open for 10 minutes.
>
> It seems to me that using Timeout (5s) here is a valid case too if
> Timeout < ProxyTimeout (as in your example) is a way to limit how long
> a client can consume httpd resources.
> So maybe we should only use the backend timeout which is an easy(er)
> way for the user to control this?

 So, the goal is to allow someone keeping the websocket open for longer
 than we usually allow for HTTP requests, to set a long ProxyTimeout or
 timeout parameter to ProxyPass.

 For HTTP/1.1 that would override the connection Timeout, since the tunnel
 poll would only use the largest value.

 For HTTP/2 I have to check how that how to accomplish that. The working
 there is different.
>>>
>>> Sorry for being a bit grumpy above, but this came out of the blue for me. 
>>> It breaks an important use case for me and the use case
>>> for the other way round was not clear to me. Maybe we can find a solution 
>>> that addresses both use cases at best by default and
>>> automatically. Any pointers for your use case such that I can have a look 
>>> and be more constructive :-).
>>>
>>
>> Thanks that you spoke up! I heard no grumpiness. ;)
> 
> Ok, testing how things *REALLY* work here, I stumbled upon:
> 
> mod_proxy_http.c:1570
> /* Let proxy tunnel forward everything within this thread */
> req->tunnel->timeout = req->idle_timeout;
> status = ap_proxy_tunnel_run(req->tunnel);
> 
> which overrides everything we discussed. So, how do we want this to work and 
> who has the final say?

Very good catch. If you look at
https://github.com/apache/httpd/blob/cc0735d1cde406c8d15016e4b2afcebb4d11fc87/modules/proxy/mod_proxy_http.c#L2009-L2023

then in the proxy case the backend timeout seems to win. Hence my crying was 
wrong and in the http proxy case things still work as
before. The above was for trunk. In case of 2.4.x we also override the setting 
from ap_proxy_tunnel_create here:
https://github.com/apache/httpd/blob/aefc30086aa71f24f77290deb88f949f36575c05/modules/proxy/mod_proxy_http.c#L1538-L1549
 in the
same fashion as we set it in ap_proxy_tunnel_create: The longest one wins.

What is actually your use case to use the shortest one? The new WebSocket over 
HTTP/2 feature? Do we get hit by the fact that on
HTTP/2 we have multiple conn_recs / streams over one TCP connection?


Regards

Rüdiger

Re: svn commit: r1910704 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Stefan Eissing via dev]

> Am 30.06.2023 um 17:22 schrieb Stefan Eissing via dev :
> 
> 
> 
>> Am 30.06.2023 um 16:45 schrieb Ruediger Pluem :
>> 
>> 
>> 
>> On 6/30/23 4:15 PM, Stefan Eissing via dev wrote:
>>> 
>>> 
 Am 30.06.2023 um 15:56 schrieb Yann Ylavic :
 
 On Fri, Jun 30, 2023 at 2:44 PM Ruediger Pluem  wrote:
> 
> On 6/30/23 11:08 AM, ic...@apache.org wrote:
>> Author: icing
>> Date: Fri Jun 30 09:08:23 2023
>> New Revision: 1910704
>> 
>> URL: http://svn.apache.org/viewvc?rev=1910704&view=rev
>> Log:
>> proxy: in proxy tunnels, use the smaller timeout value of
>> client and origin as timeout for polling the tunnel.
>> 
>> 
>> Modified:
>>  httpd/httpd/trunk/modules/proxy/proxy_util.c
>> 
>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1910704&r1=1910703&r2=1910704&view=diff
>> ==
>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Fri Jun 30 09:08:23 2023
>> @@ -4921,9 +4921,9 @@ PROXY_DECLARE(apr_status_t) ap_proxy_tun
>>   apr_socket_timeout_get(tunnel->origin->pfd->desc.s, &origin_timeout);
>>   apr_socket_opt_set(tunnel->origin->pfd->desc.s, APR_SO_NONBLOCK, 1);
>> 
>> -/* Defaults to the biggest timeout of both connections */
>> -tunnel->timeout = (origin_timeout >= 0 && origin_timeout > 
>> client_timeout)?
>> -  origin_timeout : client_timeout;
>> +/* Defaults to the smallest timeout of both connections */
>> +tunnel->timeout = (client_timeout >= 0 && client_timeout < 
>> origin_timeout ?
>> +   client_timeout : origin_timeout);
> 
> Why?
 
 We discussed this (quickly) with Stefan on
 https://github.com/apache/httpd/pull/366, but hey the commit is here
 for review finally :)
 
> It was the other way round on purpose, e.g. if Timeout is set to 5 for a 
> small front end timeout and ProxyTimeout is set to
> e.g. 600 to keep Websockets open for 10 minutes.
 
 It seems to me that using Timeout (5s) here is a valid case too if
 Timeout < ProxyTimeout (as in your example) is a way to limit how long
 a client can consume httpd resources.
 So maybe we should only use the backend timeout which is an easy(er)
 way for the user to control this?
>>> 
>>> So, the goal is to allow someone keeping the websocket open for longer
>>> than we usually allow for HTTP requests, to set a long ProxyTimeout or
>>> timeout parameter to ProxyPass.
>>> 
>>> For HTTP/1.1 that would override the connection Timeout, since the tunnel
>>> poll would only use the largest value.
>>> 
>>> For HTTP/2 I have to check how that how to accomplish that. The working
>>> there is different.
>> 
>> Sorry for being a bit grumpy above, but this came out of the blue for me. It 
>> breaks an important use case for me and the use case
>> for the other way round was not clear to me. Maybe we can find a solution 
>> that addresses both use cases at best by default and
>> automatically. Any pointers for your use case such that I can have a look 
>> and be more constructive :-).
>> 
> 
> Thanks that you spoke up! I heard no grumpiness. ;)

Ok, testing how things *REALLY* work here, I stumbled upon:

mod_proxy_http.c:1570
/* Let proxy tunnel forward everything within this thread */
req->tunnel->timeout = req->idle_timeout;
status = ap_proxy_tunnel_run(req->tunnel);

which overrides everything we discussed. So, how do we want this to work and 
who has the final say?

- Stefan