<feed xmlns='http://www.w3.org/2005/Atom'>
<title>unit.git/src, branch 1.31.1-1</title>
<subtitle>Universal Web Application Server</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/'/>
<entry>
<title>Node.js: provide reasonable default paths for macOS.</title>
<updated>2023-09-26T23:14:21+00:00</updated>
<author>
<name>Konstantin Pavlov</name>
<email>thresh@nginx.com</email>
</author>
<published>2023-09-26T23:14:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=f1ce2a5ac2ba3266d525544445366fae538d7194'/>
<id>f1ce2a5ac2ba3266d525544445366fae538d7194</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Wasm: Re-add a removed 'const' qualifier in nxt_rt_wasmtime.c.</title>
<updated>2023-10-10T19:44:07+00:00</updated>
<author>
<name>Andrew Clayton</name>
<email>a.clayton@nginx.com</email>
</author>
<published>2023-09-27T20:25:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=01d185cb52af8879aeeab04765eff439feec664c'/>
<id>01d185cb52af8879aeeab04765eff439feec664c</id>
<content type='text'>
This was inadvertently removed in 76086d6d ("Wasm: Allow to set the HTTP
response status.")

Fixes: 76086d6d ("Wasm: Allow to set the HTTP response status.")
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was inadvertently removed in 76086d6d ("Wasm: Allow to set the HTTP
response status.")

Fixes: 76086d6d ("Wasm: Allow to set the HTTP response status.")
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Refactored nxt_vsprintf().</title>
<updated>2023-10-10T06:30:02+00:00</updated>
<author>
<name>Zhidao HONG</name>
<email>z.hong@f5.com</email>
</author>
<published>2023-10-10T06:30:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=9c8b9a46a42d47b29453eefc4c5dd325f59e46b4'/>
<id>9c8b9a46a42d47b29453eefc4c5dd325f59e46b4</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>HTTP: Fix URL with query string rewrite.</title>
<updated>2023-10-05T12:38:15+00:00</updated>
<author>
<name>Andrew Clayton</name>
<email>a.clayton@nginx.com</email>
</author>
<published>2023-10-04T23:36:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=30142d2a3c862eef0a32805ee3907535ada32c71'/>
<id>30142d2a3c862eef0a32805ee3907535ada32c71</id>
<content type='text'>
On Github, @rlandgrebe reported an issue when trying to rewrite URLs
that contained query strings.

With the PHP language module we were in fact segfaulting (SIGSEGV) in
libphp

  [93960.462952] unitd[20940]: segfault at 7f307cef6476 ip 00007f2f81a94577 sp 00007fff28a777d0 error 4 in libphp-8.2.so[7f2f818df000+2fd000] likely on CPU 0 (core 0, socket 0)

  #0  0x00007f2abd494577 in php_default_treat_data (arg=1, str=0x0,
      destArray=&lt;optimized out&gt;)
      at /usr/src/debug/php-8.2.10-1.fc38.x86_64/main/php_variables.c:488
  488                     if (c_var &amp;&amp; *c_var) {
  (gdb) p c_var
  $1 = 0x7f2bb8880676 &lt;error: Cannot access memory at address 0x7f2bb8880676&gt;

This was when trying to get the query string which somehow is pointing
off into the woods.

This gdb debug session when doing rewrite basically shows the core of
the issue

  (gdb) x /64bs req-&gt;fields
  ...
  0x7f7eaaaa8090: "GET"
  0x7f7eaaaa8094: "HTTP/1.1"
  0x7f7eaaaa809d: "::1"
  0x7f7eaaaa80a1: "::1"
  0x7f7eaaaa80a5: "8080"
  0x7f7eaaaa80aa: "localhost"
  0x7f7eaaaa80b4: "/test?q=a"
  0x7f7eaaaa80be: "/test"
  ...

  (gdb) p target_pos
  $4 = (void *) 0x7f7eaaaa80b4

  (gdb) p query_pos
  $6 = (void *) 0x7f7eaaaa6af6

  (gdb) p r-&gt;args-&gt;start
  $8 = (u_char *) 0x7f7ea4002b02 "q=a HTTP/1.1\r\nHost: localhost:8080\r\nUser-Agent: curl/8.0.1\r\nAccept: */*\r\n\r\n"
  (gdb) p r-&gt;target.start
  $9 = (u_char *) 0x7f7ea40040c0 "/test?q=a"

That last address, 0x7f7ea40040c0, looks out of wack, it should be
smaller than r-&gt;args-&gt;start.

That results in a calculation in nxt_router_prepare_msg()

  if (r-&gt;args-&gt;start != NULL) {
        query_pos = nxt_pointer_to(target_pos,
                                   r-&gt;args-&gt;start - r-&gt;target.start);

        nxt_unit_sptr_set(&amp;req-&gt;query, query_pos);

  } else {

that goes negative that then is stored in req-&gt;query.offset which is a
uint32_t and so wraps backwards from UINT_MAX to give us an offset of a
little under 4GiB, hence the above invalid memory access.

All this happens due to in nxt_http_rewrite() if we have a URL with a
query string, we create a new memory allocation to store the transformed
URL and query string.

We set r-&gt;target to point to this new allocation, but we also need to
point r-&gt;args-&gt;start to the start of the query string in this new
allocation.

Reported-by: René Landgrebe &lt;https://github.com/rlandgrebe&gt;
Tested-by: René Landgrebe &lt;https://github.com/rlandgrebe&gt;
Tested-by: Liam Crilly &lt;liam.crilly@nginx.com&gt;
Fixes: 14d6d97b ("HTTP: added basic URI rewrite.")
Closes: &lt;https://github.com/nginx/unit/issues/964&gt;
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On Github, @rlandgrebe reported an issue when trying to rewrite URLs
that contained query strings.

With the PHP language module we were in fact segfaulting (SIGSEGV) in
libphp

  [93960.462952] unitd[20940]: segfault at 7f307cef6476 ip 00007f2f81a94577 sp 00007fff28a777d0 error 4 in libphp-8.2.so[7f2f818df000+2fd000] likely on CPU 0 (core 0, socket 0)

  #0  0x00007f2abd494577 in php_default_treat_data (arg=1, str=0x0,
      destArray=&lt;optimized out&gt;)
      at /usr/src/debug/php-8.2.10-1.fc38.x86_64/main/php_variables.c:488
  488                     if (c_var &amp;&amp; *c_var) {
  (gdb) p c_var
  $1 = 0x7f2bb8880676 &lt;error: Cannot access memory at address 0x7f2bb8880676&gt;

This was when trying to get the query string which somehow is pointing
off into the woods.

This gdb debug session when doing rewrite basically shows the core of
the issue

  (gdb) x /64bs req-&gt;fields
  ...
  0x7f7eaaaa8090: "GET"
  0x7f7eaaaa8094: "HTTP/1.1"
  0x7f7eaaaa809d: "::1"
  0x7f7eaaaa80a1: "::1"
  0x7f7eaaaa80a5: "8080"
  0x7f7eaaaa80aa: "localhost"
  0x7f7eaaaa80b4: "/test?q=a"
  0x7f7eaaaa80be: "/test"
  ...

  (gdb) p target_pos
  $4 = (void *) 0x7f7eaaaa80b4

  (gdb) p query_pos
  $6 = (void *) 0x7f7eaaaa6af6

  (gdb) p r-&gt;args-&gt;start
  $8 = (u_char *) 0x7f7ea4002b02 "q=a HTTP/1.1\r\nHost: localhost:8080\r\nUser-Agent: curl/8.0.1\r\nAccept: */*\r\n\r\n"
  (gdb) p r-&gt;target.start
  $9 = (u_char *) 0x7f7ea40040c0 "/test?q=a"

That last address, 0x7f7ea40040c0, looks out of wack, it should be
smaller than r-&gt;args-&gt;start.

That results in a calculation in nxt_router_prepare_msg()

  if (r-&gt;args-&gt;start != NULL) {
        query_pos = nxt_pointer_to(target_pos,
                                   r-&gt;args-&gt;start - r-&gt;target.start);

        nxt_unit_sptr_set(&amp;req-&gt;query, query_pos);

  } else {

that goes negative that then is stored in req-&gt;query.offset which is a
uint32_t and so wraps backwards from UINT_MAX to give us an offset of a
little under 4GiB, hence the above invalid memory access.

All this happens due to in nxt_http_rewrite() if we have a URL with a
query string, we create a new memory allocation to store the transformed
URL and query string.

We set r-&gt;target to point to this new allocation, but we also need to
point r-&gt;args-&gt;start to the start of the query string in this new
allocation.

Reported-by: René Landgrebe &lt;https://github.com/rlandgrebe&gt;
Tested-by: René Landgrebe &lt;https://github.com/rlandgrebe&gt;
Tested-by: Liam Crilly &lt;liam.crilly@nginx.com&gt;
Fixes: 14d6d97b ("HTTP: added basic URI rewrite.")
Closes: &lt;https://github.com/nginx/unit/issues/964&gt;
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Added routes array to the default configuration.</title>
<updated>2023-10-02T08:43:57+00:00</updated>
<author>
<name>Liam Crilly</name>
<email>liam.crilly@nginx.com</email>
</author>
<published>2023-10-02T08:43:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=7fac9087424e1f7c4b82bfb8426aca197f1f8904'/>
<id>7fac9087424e1f7c4b82bfb8426aca197f1f8904</id>
<content type='text'>
The default configuration previously contained just a listeners and
applications object. Since routes is now a principle configuration object,
and a recommended way of configurating Unit, it is now included in the
default configuration.

This change benefits new users because it explicitly introduces the three
principle configuration objects which leads more intuitively to the
documentation. Experienced users may choose to ignore or delete routes.

routes is defined as an array instead of an object because this change
is designed to assist new users, where the simpler form of routes is
easier to understand.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The default configuration previously contained just a listeners and
applications object. Since routes is now a principle configuration object,
and a recommended way of configurating Unit, it is now included in the
default configuration.

This change benefits new users because it explicitly introduces the three
principle configuration objects which leads more intuitively to the
documentation. Experienced users may choose to ignore or delete routes.

routes is defined as an array instead of an object because this change
is designed to assist new users, where the simpler form of routes is
easier to understand.
</pre>
</div>
</content>
</entry>
<entry>
<title>Java: fixed the calculation related to the response buffer.</title>
<updated>2023-09-28T14:21:16+00:00</updated>
<author>
<name>Zhidao HONG</name>
<email>z.hong@f5.com</email>
</author>
<published>2023-09-28T14:14:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=b6216f0bb7c4e10afcec00c6660644ff32db0dfb'/>
<id>b6216f0bb7c4e10afcec00c6660644ff32db0dfb</id>
<content type='text'>
We need to take into account the size of the nxt_unit_response_t
structure itself when calculating where to start appending data to in
memory.

Closes: &lt;https://github.com/nginx/unit/issues/923&gt;
Reported-by: Alejandro Colomar &lt;alx@kernel.org&gt;
Reviewed-by: Andrew Clayton &lt;a.clayton@nginx.org&gt;
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need to take into account the size of the nxt_unit_response_t
structure itself when calculating where to start appending data to in
memory.

Closes: &lt;https://github.com/nginx/unit/issues/923&gt;
Reported-by: Alejandro Colomar &lt;alx@kernel.org&gt;
Reviewed-by: Andrew Clayton &lt;a.clayton@nginx.org&gt;
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Node.js: ServerRequest.destroy() implemented.</title>
<updated>2023-09-26T11:49:39+00:00</updated>
<author>
<name>Andrei Zeliankou</name>
<email>zelenkov@nginx.com</email>
</author>
<published>2023-09-26T11:49:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=2d0e502d2a69ad490e0633c59636e1115afa983d'/>
<id>2d0e502d2a69ad490e0633c59636e1115afa983d</id>
<content type='text'>
This closes #871 issue on GitHub.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This closes #871 issue on GitHub.
</pre>
</div>
</content>
</entry>
<entry>
<title>Node.js: response body chunk can now be a Uint8Array.</title>
<updated>2023-09-26T11:49:39+00:00</updated>
<author>
<name>Andrei Zeliankou</name>
<email>zelenkov@nginx.com</email>
</author>
<published>2023-09-26T11:49:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=e0c26757740fa7974af6e6592e35b5f2e00339fe'/>
<id>e0c26757740fa7974af6e6592e35b5f2e00339fe</id>
<content type='text'>
Starting from Node.js 15.0.0 the chunk parameter of the response.write()
can be a Uint8Array.

This closes #870 issue on GitHub.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Starting from Node.js 15.0.0 the chunk parameter of the response.write()
can be a Uint8Array.

This closes #870 issue on GitHub.
</pre>
</div>
</content>
</entry>
<entry>
<title>Wasm: Allow uploads larger than 4GiB.</title>
<updated>2023-09-25T12:52:13+00:00</updated>
<author>
<name>Andrew Clayton</name>
<email>a.clayton@nginx.com</email>
</author>
<published>2023-09-14T19:35:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=0f630c3f604e76de370529907b51ad29dfdc4ecb'/>
<id>0f630c3f604e76de370529907b51ad29dfdc4ecb</id>
<content type='text'>
Currently Wasm modules are limited to a 32bit address space (until at
least the memory64 work is completed). All the counters etc in the
request structure were u32's. Which matched with 32bit memory
limitation.

However there is really no need to not allow &gt;4GiB uploads that can be
saved off to disk or some such.

To do this we just need to increase the -&gt;content_len &amp;
-&gt;total_content_sent members to u64's.

However because we need the request structure to have the exact same
layout on 32bit (for Wasm modules) as it does on 64bit we need to re-jig
the order of some of these members and add a four-byte padding member.

Thus the request structure now looks like on 64bit (as shown by
pahole(1))

  struct nxt_wasm_request_s {
          uint32_t                   method_off;           /*     0     4 */
          uint32_t                   method_len;           /*     4     4 */
          uint32_t                   version_off;          /*     8     4 */
          uint32_t                   version_len;          /*    12     4 */
          uint32_t                   path_off;             /*    16     4 */
          uint32_t                   path_len;             /*    20     4 */
          uint32_t                   query_off;            /*    24     4 */
          uint32_t                   query_len;            /*    28     4 */
          uint32_t                   remote_off;           /*    32     4 */
          uint32_t                   remote_len;           /*    36     4 */
          uint32_t                   local_addr_off;       /*    40     4 */
          uint32_t                   local_addr_len;       /*    44     4 */
          uint32_t                   local_port_off;       /*    48     4 */
          uint32_t                   local_port_len;       /*    52     4 */
          uint32_t                   server_name_off;      /*    56     4 */
          uint32_t                   server_name_len;      /*    60     4 */
          /* --- cacheline 1 boundary (64 bytes) --- */
          uint64_t                   content_len;          /*    64     8 */
          uint64_t                   total_content_sent;   /*    72     8 */
          uint32_t                   content_sent;         /*    80     4 */
          uint32_t                   content_off;          /*    84     4 */
          uint32_t                   request_size;         /*    88     4 */
          uint32_t                   nfields;              /*    92     4 */
          uint32_t                   tls;                  /*    96     4 */
          char                       __pad[4];             /*   100     4 */
          nxt_wasm_http_field_t      fields[];             /*   104     0 */

          /* size: 104, cachelines: 2, members: 25 */
          /* last cacheline: 40 bytes */
  };

and the same structure (taken from unit-wasm) compiled as 32bit

  struct luw_req {
          u32                        method_off;           /*     0     4 */
          u32                        method_len;           /*     4     4 */
          u32                        version_off;          /*     8     4 */
          u32                        version_len;          /*    12     4 */
          u32                        path_off;             /*    16     4 */
          u32                        path_len;             /*    20     4 */
          u32                        query_off;            /*    24     4 */
          u32                        query_len;            /*    28     4 */
          u32                        remote_off;           /*    32     4 */
          u32                        remote_len;           /*    36     4 */
          u32                        local_addr_off;       /*    40     4 */
          u32                        local_addr_len;       /*    44     4 */
          u32                        local_port_off;       /*    48     4 */
          u32                        local_port_len;       /*    52     4 */
          u32                        server_name_off;      /*    56     4 */
          u32                        server_name_len;      /*    60     4 */
          /* --- cacheline 1 boundary (64 bytes) --- */
          u64                        content_len;          /*    64     8 */
          u64                        total_content_sent;   /*    72     8 */
          u32                        content_sent;         /*    80     4 */
          u32                        content_off;          /*    84     4 */
          u32                        request_size;         /*    88     4 */
          u32                        nr_fields;            /*    92     4 */
          u32                        tls;                  /*    96     4 */
          char                       __pad[4];             /*   100     4 */
          struct luw_hdr_field       fields[];             /*   104     0 */

          /* size: 104, cachelines: 2, members: 25 */
          /* last cacheline: 40 bytes */
  };

We can see the structures have the same layout, same size and no
padding.

We need the __pad member as otherwise I saw gcc and clang on Alpine
Linux automatically add the 'packed' attribute to the structure which
made the two structures not match.

Link: &lt;https://github.com/WebAssembly/memory64&gt;
Link: &lt;https://github.com/nginx/unit-wasm&gt;
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently Wasm modules are limited to a 32bit address space (until at
least the memory64 work is completed). All the counters etc in the
request structure were u32's. Which matched with 32bit memory
limitation.

However there is really no need to not allow &gt;4GiB uploads that can be
saved off to disk or some such.

To do this we just need to increase the -&gt;content_len &amp;
-&gt;total_content_sent members to u64's.

However because we need the request structure to have the exact same
layout on 32bit (for Wasm modules) as it does on 64bit we need to re-jig
the order of some of these members and add a four-byte padding member.

Thus the request structure now looks like on 64bit (as shown by
pahole(1))

  struct nxt_wasm_request_s {
          uint32_t                   method_off;           /*     0     4 */
          uint32_t                   method_len;           /*     4     4 */
          uint32_t                   version_off;          /*     8     4 */
          uint32_t                   version_len;          /*    12     4 */
          uint32_t                   path_off;             /*    16     4 */
          uint32_t                   path_len;             /*    20     4 */
          uint32_t                   query_off;            /*    24     4 */
          uint32_t                   query_len;            /*    28     4 */
          uint32_t                   remote_off;           /*    32     4 */
          uint32_t                   remote_len;           /*    36     4 */
          uint32_t                   local_addr_off;       /*    40     4 */
          uint32_t                   local_addr_len;       /*    44     4 */
          uint32_t                   local_port_off;       /*    48     4 */
          uint32_t                   local_port_len;       /*    52     4 */
          uint32_t                   server_name_off;      /*    56     4 */
          uint32_t                   server_name_len;      /*    60     4 */
          /* --- cacheline 1 boundary (64 bytes) --- */
          uint64_t                   content_len;          /*    64     8 */
          uint64_t                   total_content_sent;   /*    72     8 */
          uint32_t                   content_sent;         /*    80     4 */
          uint32_t                   content_off;          /*    84     4 */
          uint32_t                   request_size;         /*    88     4 */
          uint32_t                   nfields;              /*    92     4 */
          uint32_t                   tls;                  /*    96     4 */
          char                       __pad[4];             /*   100     4 */
          nxt_wasm_http_field_t      fields[];             /*   104     0 */

          /* size: 104, cachelines: 2, members: 25 */
          /* last cacheline: 40 bytes */
  };

and the same structure (taken from unit-wasm) compiled as 32bit

  struct luw_req {
          u32                        method_off;           /*     0     4 */
          u32                        method_len;           /*     4     4 */
          u32                        version_off;          /*     8     4 */
          u32                        version_len;          /*    12     4 */
          u32                        path_off;             /*    16     4 */
          u32                        path_len;             /*    20     4 */
          u32                        query_off;            /*    24     4 */
          u32                        query_len;            /*    28     4 */
          u32                        remote_off;           /*    32     4 */
          u32                        remote_len;           /*    36     4 */
          u32                        local_addr_off;       /*    40     4 */
          u32                        local_addr_len;       /*    44     4 */
          u32                        local_port_off;       /*    48     4 */
          u32                        local_port_len;       /*    52     4 */
          u32                        server_name_off;      /*    56     4 */
          u32                        server_name_len;      /*    60     4 */
          /* --- cacheline 1 boundary (64 bytes) --- */
          u64                        content_len;          /*    64     8 */
          u64                        total_content_sent;   /*    72     8 */
          u32                        content_sent;         /*    80     4 */
          u32                        content_off;          /*    84     4 */
          u32                        request_size;         /*    88     4 */
          u32                        nr_fields;            /*    92     4 */
          u32                        tls;                  /*    96     4 */
          char                       __pad[4];             /*   100     4 */
          struct luw_hdr_field       fields[];             /*   104     0 */

          /* size: 104, cachelines: 2, members: 25 */
          /* last cacheline: 40 bytes */
  };

We can see the structures have the same layout, same size and no
padding.

We need the __pad member as otherwise I saw gcc and clang on Alpine
Linux automatically add the 'packed' attribute to the structure which
made the two structures not match.

Link: &lt;https://github.com/WebAssembly/memory64&gt;
Link: &lt;https://github.com/nginx/unit-wasm&gt;
Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Wasm: Fix multiple successive calls to the request_handler.</title>
<updated>2023-09-25T12:52:13+00:00</updated>
<author>
<name>Andrew Clayton</name>
<email>a.clayton@nginx.com</email>
</author>
<published>2023-09-13T23:37:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/unit.git/commit/?id=d5efa5f11f38d4ca6c64374f848055611d4f315c'/>
<id>d5efa5f11f38d4ca6c64374f848055611d4f315c</id>
<content type='text'>
When trying to upload files to the luw-upload-reflector demo[0] above a
certain size that would mean Unit would need to make more than two calls
to the request_handler function in the Wasm module we would get the
following error from wasmtime and the upload would stall on the third
call to the request_handler

  WASMTIME ERROR: failed to call function [-&gt;wasm_request_handler]
  error while executing at wasm backtrace:
      0: 0x5ce2 - &lt;unknown&gt;!memcpy
      1:  0x7df - luw_req_buf_append
                      at /home/andrew/src/unit-wasm/src/c/libunit-wasm.c:308:14
      2:  0x3a1 - luw_request_handler
                      at /home/andrew/src/unit-wasm/examples/c/luw-upload-reflector.c:110:3

  Caused by:
      wasm trap: out of bounds memory access

This was due to -&gt;content_off (the offset of where the actual body
content starts in the request structure/memory) being some overly large
value.

This was largely down to me being an idiot!

Before calling the loop that makes the calls to the request_handler we
would calculate the new offset, which is now just the size of the
request structure as we don't re-send all the HTTP meta data and headers
etc. However because this value is in the request structure which is in
the shared memory and we use this same memory for requests and
responses, when we make a response we overwrite this request structure
with the response structure, so our -&gt;content_off is now some wacked out
value when we make the next call to the request_handler.

To fix this we just need to reset -&gt;content_off each time round the
loop.

There's also no point in setting -&gt;nfields to 0, it has the same issue
as above, but doesn't get re-used by the Wasm module anyway.

[0]: &lt;https://github.com/nginx/unit-wasm/blob/main/examples/c/luw-upload-reflector.c&gt;

Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When trying to upload files to the luw-upload-reflector demo[0] above a
certain size that would mean Unit would need to make more than two calls
to the request_handler function in the Wasm module we would get the
following error from wasmtime and the upload would stall on the third
call to the request_handler

  WASMTIME ERROR: failed to call function [-&gt;wasm_request_handler]
  error while executing at wasm backtrace:
      0: 0x5ce2 - &lt;unknown&gt;!memcpy
      1:  0x7df - luw_req_buf_append
                      at /home/andrew/src/unit-wasm/src/c/libunit-wasm.c:308:14
      2:  0x3a1 - luw_request_handler
                      at /home/andrew/src/unit-wasm/examples/c/luw-upload-reflector.c:110:3

  Caused by:
      wasm trap: out of bounds memory access

This was due to -&gt;content_off (the offset of where the actual body
content starts in the request structure/memory) being some overly large
value.

This was largely down to me being an idiot!

Before calling the loop that makes the calls to the request_handler we
would calculate the new offset, which is now just the size of the
request structure as we don't re-send all the HTTP meta data and headers
etc. However because this value is in the request structure which is in
the shared memory and we use this same memory for requests and
responses, when we make a response we overwrite this request structure
with the response structure, so our -&gt;content_off is now some wacked out
value when we make the next call to the request_handler.

To fix this we just need to reset -&gt;content_off each time round the
loop.

There's also no point in setting -&gt;nfields to 0, it has the same issue
as above, but doesn't get re-used by the Wasm module anyway.

[0]: &lt;https://github.com/nginx/unit-wasm/blob/main/examples/c/luw-upload-reflector.c&gt;

Signed-off-by: Andrew Clayton &lt;a.clayton@nginx.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
