ci: run test suite against nginx master in addition to 1.30.0

[Copilot]

CI only validated the module against nginx 1.30.0; master was never tested despite being listed as supported.

Changes

• Extended matrix in .github/workflows/test-nginx-1.30.yml from a single nginx-version list to an include matrix with two entries:

matrix:
  include:
    - label: "1.30.0"
      source: release
      nginx-version: "1.30.0"
    - label: master
      source: master
      nginx-version: master

• Split download from build: extracted a Download nginx source step with a shell conditional — tagged tarball for release, refs/heads/master.tar.gz for master. Build and prove -r steps are shared across both legs unchanged.
• Renamed workflow from test nginx 1.30 → test nginx to reflect broader coverage.

Original prompt

Update the GitHub Actions workflow in repository Securepoint/nginx-ntlm-modulev2 so the existing test suite also runs against nginx master in addition to nginx 1.30.0.

Requirements:

• Modify the existing workflow at .github/workflows/test-nginx-1.30.yml.
• Preserve the current test steps and behavior for nginx 1.30.0.
• Extend the job matrix so the same test suite runs for both:
  • nginx release 1.30.0
  • nginx master
• For the release case, continue downloading the tagged tarball using the existing release URL pattern.
• For the master case, download the master branch tarball from the nginx repository.
• Build nginx from the downloaded source with ./auto/configure --prefix="$RUNNER_TEMP/nginx" --add-module="$GITHUB_WORKSPACE", then run the existing Perl test suite with prove -r "$GITHUB_WORKSPACE/t".
• Keep the workflow valid YAML and keep it triggered on push to main and on pull requests.

Please create a pull request with the workflow change.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: can you explain what the testsuite actually does?

Assistant: Yes — the testsuite is basically an integration test harness for the nginx NTLM module, not a unit test suite.

What it does, in plain terms:

• builds/runs nginx with this module enabled,
• starts a fake backend server written in Node.js,
• sends requests through nginx,
• and checks whether nginx keeps the same upstream connection pinned to the right backend when NTLM/Negotiate auth is involved.

Core idea being tested

NTLM and Negotiate are connection-oriented auth schemes. That means once a client authenticates, nginx must keep reusing the same upstream TCP connection for that client/session, otherwise auth breaks.

The fake backend in t/backend/index.js simulates that behavior by storing the auth token on the backend connection and echoing it back on later requests as X-NGX-NTLM-AUTH.

So the suite is asking:

• did nginx pin later requests to the same upstream connection?
• did the token stay associated with that connection?
• was the connection dropped when it should be?
• did cleanup/eviction/limits behave safely?

How the harness works

From README.md, tests are run with Perl’s Test::Nginx:

• install backend deps with npm install -C t/backend
• install Perl test framework Test::Nginx
• run prove -r t

GitHub Actions does the same in .github/workflows/test-nginx-1.30.yml:

• installs Node + Perl deps
• builds nginx 1.30 with --add-module="$GITHUB_WORKSPACE"
• runs prove -r "$GITHUB_WORKSPACE/t"

The fake backend

t/backend/index.js starts two Express servers on ports 19841 and 19842.

Its behavior:

• if a request has Authorization: NTLM ... or Authorization: Negotiate ..., it extracts the token
• it stores that token on req.connection.xauthData
• on later requests over the same backend connection, it returns X-NGX-NTLM-AUTH: <token>
• response body is always just OK

That means:

• if nginx reuses the same upstream socket, later requests still get the same token header
• if nginx switches to a different backend connection, the token header disappears or changes

What each test file covers

t/001-sanity.t

This checks the basic expected behavior.

Main cases:

1. NTLM triggers connection pinning

   • first request sends Authorization: NTLM <token>
   • following pipelined requests send no auth header
   • expected: backend still returns the same X-NGX-NTLM-AUTH
   • meaning: nginx reused the authenticated upstream connection

2. Negotiate does the same

   • same as above, but with Authorization: Negotiate <token>

3. Client disconnect cleanup

   • verifies that if the client connection dies, the backend pinned connection is also cleaned up properly
   • this is about avoiding leaked or stale upstream connections

t/002-timeout.t

This tests behavior when the NTLM upstream cache entry times out.

Key config:

• ntlm_timeout 2s;

Cases:

1. Client drops connection after backend timeout

   • backend connection expires
   • then client cleanup happens
   • expected: nginx does not crash and no errors are logged

2. Client sends another request after timeout

   • initial requests use authenticated pinned connection
   • after timeout, a later request should no longer reuse that expired connection
   • expected: token header disappears on the later request

So this file is mostly regression testing around timeout-related cleanup and crash safety.

t/003-stress.t

This is more of an edge-case/regression suite for cache pressure and lifetime limits.

Visible tests include:

1. Cache eviction under saturation

   • config uses ntlm 2;
   • only 2 cached auth-bound upstream connections allowed
   • then 3 different credentials are used
   • expected: oldest cache entry gets evicted cleanly, without corrupting internal lists

2. ntlm_requests boundary

   • config uses `ntl...

This pull request was created from Copilot chat.