OAK: a component server block receives all requests on oak['network_address']

This description was written by Claude Code, from an empirical test session. A human reviewed it before it was posted.

Summary

When oak['enable'] is true and oak['network_address'] has a value, nginx sends all requests on that address to one OAK component. nginx ignores the Host header. GitLab is not available on that address.

This defect is on master. Commit f653ef53 (2026-06-11) added the cause. The Artifact Registry merge requests do not cause this defect, but they make it visible.

Cause

  1. Nginx.parse_nginx_listen_addresses adds oak['network_address'] to nginx['listen_addresses']. The function tests only oak['enable']. A component or a request for network exposure is not necessary.

  2. The GitLab server block reads a different attribute: node['gitlab']['gitlab_rails']['nginx'] (gitlab/recipes/nginx.rb:41). The change in step 1 does not apply to it.

  3. The two server blocks are then different:

    gitlab-rails.conf:35              listen *:80 default_server;
gitlab-artifact_registry.conf:17  listen *:80;
gitlab-artifact_registry.conf:18  listen 172.28.0.10:80;

  4. nginx selects the socket before it reads the Host header. Only the component server block has the socket for 172.28.0.10:80. That server block is thus the only server, and also the default server, for this address.

The intended result of step 1 does not occur. The unwanted result occurs.

Runtime values that show the difference:

node[nginx][listen_addresses]                       = ['*', '172.28.0.10']
node[gitlab][gitlab_rails][nginx][listen_addresses] = None

Effect

Artifact Registry reads the GitLab signature keys (JWKS) through this address. The read operation fails with HTTP 404. The container then stops and starts again many times:

"token-exchange: JWKS fetch failed"
"jwk.Fetch: request returned status 404, expected 200"

A reconfigure operation or a host restart is sufficient to cause this failure. An installation that operates correctly can thus fail without a change to its configuration. The error message shows HTTP 404 from GitLab. The message does not show the nginx configuration, and it can send the operator in the wrong direction.

OpenBao has the same defect on master today. OpenBao does not read data from GitLab, and OpenBao continues to operate. Only the other traffic to that address fails. This is why the defect stayed unknown from June.

How to reproduce

  1. Start an Omnibus node with oak['enable'] = true and oak['network_address'] = '172.28.0.10'.

  2. Enable one OAK component. Give it an external_url and an internal_url.

  3. Do a reconfigure operation.

  4. Send a request to the GitLab hostname at the OAK address:

    curl -H 'Host: gitlab.example.com' http://172.28.0.10/

The component answers the request. GitLab does not answer the request. A request to 127.0.0.1 with the same Host header shows the correct GitLab answer.

Correction

Remove oak['network_address'] from the listen addresses of the component server block. The listen *:80 directive already accepts connections to that address. All server blocks then use one socket, and nginx reads the Host header correctly.

The correction is one line. Tests done in the container show these results:

Request Before After
JWKS from a pod 404 200
Host: gitlab.* at the OAK address component GitLab (302)
Host: artifacts.* at the OAK address component component

An alternative is to add the same address to the GitLab server block. This alternative is correct, but it needs more code.

Tests

No test finds this defect. Each test examines one server block only. ChefSpec cannot find it, because ChefSpec does not start nginx.

Add a test that has two server blocks on one address. The test must send a request for each hostname and examine the two answers.