DEV Community: Alex Tsang

Avoid leaking resources in Deno tests

Alex Tsang — Sat, 30 May 2020 15:10:48 +0000

Recently I have been using Deno to implement a simple web API to play with the new TypeScript runtime. In order to test the APIs, today I wrote a test, which is similar to the following:

import {
  assertStrictEq,
} from "https://deno.land/std@v0.51.0/testing/asserts.ts";

import {
  Application,
} from "https://deno.land/x/oak@v5.0.0/mod.ts";

Deno.test("server with a simple middleware", async () => {
  const app = new Application();
  const controller  = new AbortController();
  const { signal } = controller;

  app.use(async (ctx) => {
    ctx.response.body = 'Hello world.';
  });

  const listenPromise = app.listen({ port: 8000, signal });

  const response = await fetch("http://127.0.0.1:8000/");
  assertStrictEq(response.ok, true);

  controller.abort();

  await listenPromise;
});

The test is simple:

Create a new application.
Mount a middleware on the application so that the application will respond with "Hello world." when a request arrives.
Start the application and listen on the specified port (i.e. 8000).
Send a request to the application and test whether the response status code is in expected range (response.ok means the status is in the range 200 - 299).
Stop the application.

This test should pass... Except when it didn't:

> deno test --allow-net
running 1 tests
test server with a simple middleware ... FAILED (38ms)

failures:

server with a simple middleware
AssertionError: Test case is leaking resources.
Before: {
  "0": "stdin",
  "1": "stdout",
  "2": "stderr"
}
After: {
  "0": "stdin",
  "1": "stdout",
  "2": "stderr",
  "5": "httpBody"
}

Make sure to close all open resource handles returned from Deno APIs before
finishing test case.
    at Object.assert ($deno$/util.ts:33:11)
    at Object.resourceSanitizer [as fn] ($deno$/testing.ts:81:5)
    at async TestApi.[Symbol.asyncIterator] ($deno$/testing.ts:264:11)
    at async Object.runTests ($deno$/testing.ts:346:20)

failures:

        server with a simple middleware

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out (42ms)

At first I didn't understand which part of the test was leaking resources. After some experiments, I found that the root cause was that I didn't read the response body obtained from the fetch() function call.

After calling await fetch() to obtain the response, one can call response.text() (or response.json()) to read the response stream and parse it as JSON data (or plain text) (see the document on MDN for details). Without reading the response stream (which is expected to be read, I guess), Deno would think the test is leaking resources.

It is very simple to fix the problem. When using Deno 1.0.3 (the latest version at the time of writing), one can call cancel() on the response stream to say that the data is not needed anymore. I updated the test:

import {
  assertStrictEq,
} from "https://deno.land/std@v0.51.0/testing/asserts.ts";

import {
  Application,
} from "https://deno.land/x/oak@v5.0.0/mod.ts";

Deno.test("server with a simple middleware", async () => {
  const app = new Application();
  const controller  = new AbortController();
  const { signal } = controller;

  app.use(async (ctx) => {
    ctx.response.body = 'Hello world.';
  });

  const listenPromise = app.listen({ port: 8000, signal });

  const response = await fetch("http://127.0.0.1:8000/");
  assertStrictEq(response.ok, true);
  // The response body is not needed.
  await response.body?.cancel();

  controller.abort();

  await listenPromise;
});

Notice that line after checking the response status:

await response.body?.cancel();

(See Optional chaining if you wonder what does ?. mean.)

Finally the test passed:

> deno test --allow-net
running 1 tests
test server with a simple middleware ... ok (89ms)

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (93ms)

If you are using Deno 1.0.2 (or previous versions), the cancel() function is not implemented:

> deno test --allow-net
running 1 tests
test server with a simple middleware ... FAILED (71ms)

failures:

server with a simple middleware
Error: not implemented
    at Object.notImplemented ($deno$/util.ts:64:9)
    at Body.cancel ($deno$/web/fetch.ts:234:12)

You can still read the response body and throw it away immediately:

await response.text();

In fact, the same leaking resources problem has been asked and addressed around a month ago, you can see the issue #4735 on Deno's code repository for more details.

Some useful links:

Notes on configuring HAProxy on OpenBSD 6.7 with Mozilla SSL Configuration Generator

Alex Tsang — Thu, 21 May 2020 17:19:07 +0000

2021-05-06 update: At the time of writing this article, I thought the lack of TLSv1.3 support was due to the missing API in LibreSSL, but in fact LibreSSL didn't even support TLSv1.3 on server-side until version 3.2.0 was released (later than OpenBSD 6.7 was released). See the release notes for details. On OpenBSD 6.9, the pre-built HAProxy package supports TLSv1.3.

OpenBSD 6.7 was released on 2020-05-19. I upgraded one of my servers from OpenBSD 6.6 to OpenBSD 6.7 that night.

Before the OpenBSD 6.7 was available, I already noticed that the HAProxy package has been upgraded from 1.9 to 2.0 in the ports tree. So after upgrading the OS, I upgraded the installed packages (including HAProxy) by:

pkg_add -u

TLS 1.3

Once I have upgraded the HAProxy installed on my server, I used the Mozilla SSL Configuration Generator to generate a "Modern" configuration. Part of the generated configuration looked like this:

global
  ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
  ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets
  ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
  ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets

I immediately noticed something "wrong". On OpenBSD 6.7, the pre-built HAProxy says the following TLS versions are supported:

# haproxy -vv | grep TLSv
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2

Compared to the pre-built HAProxy on Alpine Linux 3.11:

# haproxy -vv | grep TLSv
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3

The output above shows that the pre-built HAProxy on OpenBSD 6.7 does not support TLSv1.3 (while the one on Alpine Linux 3.11 does). So the configuration generated by Mozilla SSL Configuration Generator effectively disables all SSL/ TLS versions. In fact, I tried to apply the configuration and let HAProxy check it:

# haproxy -c -f haproxy.cfg.new
...
[ALERT] 140/031748 (28829) : Proxy 'frontend-01': all SSL/TLS versions are disabled for bind ':443' at [/etc/haproxy/haproxy.cfg.new:17].
...
[ALERT] 140/031748 (28829) : Fatal errors found in configuration.
...

In addition, the ssl-default-bind-ciphersuites setting does not work in HAProxy on OpenBSD 6.7. From the HAProxy Documentation:

This setting is only available when support for OpenSSL was built in and OpenSSL 1.1.1 or later was used to build HAProxy.

HAProxy on OpenBSD 6.7 is built with LibreSSL 3.1.1 and the TLS 1.3 API is not available at the moment. From the release notes of LibreSSL 3.1.1:

Note that the OpenSSL TLS 1.3 API is not yet visible/available.

Hopefully the API will be ready by the time when OpenBSD 6.8 is released.

Bonus

On OpenBSD 6.6, the pre-built HAProxy does not support compression:

# haproxy -vv | grep Compression
Compression algorithms supported : identity("identity")

According to the HAProxy Documentation:

Identity does not apply any change on data.

Luckily, on OpenBSD 6.7, the pre-built HAProxy comes with compression support:

# haproxy -vv | grep Compression
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")

That means I can enable compression in HAProxy with the following line:

compression algo gzip

Also note that reqrep has been deprecated. From the HAProxy Documentation:

Using "reqadd"/"reqdel"/"reqrep" to manipulate request headers is discouraged in newer versions (>= 1.5).

In HAProxy 2.0 (according to the release notes, starting from 2.0-dev4), error message will be printed if the directive is being used:

The 'reqrep' directive is deprecated in favor of 'http-request replace-uri', 'http-request replace-path', and 'http-request replace-header' and will be removed in next version.

References

For reference, this is the HAProxy's version and build options on OpenBSD 6.6:

HA-Proxy version 1.9.15 2020/04/02 - https://haproxy.org/
Build options :
  TARGET  = openbsd
  CPU     = generic
  CC      = cc
  CFLAGS  = -O2 -pipe -fno-strict-aliasing
  OPTIONS = USE_OPENSSL=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : LibreSSL 3.0.2
Running on OpenSSL version : LibreSSL 3.0.2
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: SO_BINDANY
Built without compression support (neither USE_ZLIB nor USE_SLZ are set).
Compression algorithms supported : identity("identity")
Built with PCRE version : 8.41 2017-07-05
Running on PCRE version : 8.41 2017-07-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes
Built with multi-threading support.

Available polling systems :
     kqueue : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use kqueue.

Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
              h2 : mode=HTTP       side=FE
              h2 : mode=HTX        side=FE|BE
       <default> : mode=HTX        side=FE|BE
       <default> : mode=TCP|HTTP   side=FE|BE

Available filters :
        [SPOE] spoe
        [COMP] compression
        [CACHE] cache
        [TRACE] trace

On OpenBSD 6.7:

HA-Proxy version 2.0.14 2020/04/02 - https://haproxy.org/
Build options :
  TARGET  = openbsd
  CPU     = generic
  CC      = cc
  CFLAGS  = -O2 -pipe -fno-strict-aliasing
  OPTIONS = USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1

Feature list : -EPOLL +KQUEUE -MY_EPOLL -MY_SPLICE -NETFILTER +PCRE -PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM -STATIC_PCRE -STATIC_PCRE2 +TPROXY -LINUX_TPROXY -LINUX_SPLICE -LIBCRYPT -CRYPT_H -VSYSCALL -GETADDRINFO +OPENSSL -LUA -FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB -SLZ -CPU_AFFINITY -TFO -NS -DL -RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER -PRCTL -THREAD_DUMP -EVPORTS

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=1).
Built with OpenSSL version : LibreSSL 3.1.1
Running on OpenSSL version : LibreSSL 3.1.1
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: SO_BINDANY
Built with zlib version : 1.2.3
Running on zlib version : 1.2.3
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.41 2017-07-05
Running on PCRE version : 8.41 2017-07-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes

Available polling systems :
     kqueue : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use kqueue.

Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
              h2 : mode=HTTP       side=FE        mux=H2
              h2 : mode=HTX        side=FE|BE     mux=H2
       <default> : mode=HTX        side=FE|BE     mux=H1
       <default> : mode=TCP|HTTP   side=FE|BE     mux=PASS

Available services : none

Available filters :
        [SPOE] spoe
        [COMP] compression
        [CACHE] cache
        [TRACE] trace

And some useful links:

Oh, if you also like the work from the OpenBSD developers, please consider donating to the OpenBSD Foundation.