`--custom-header` is not sent on the `contracts/publish` request, only on the initial HAL discovery request

[tomasnarvoisas-dotcom]

Environment

• @pact-foundation/pact-cli: 18.1.1
• Underlying binary: pact-broker-cli / pact_broker_cli, user-agent: pact-broker-cli/0.8.4
• OS: macOS (darwin)
• Command: pact-broker publish

Description

pact-broker publish performs two HTTP requests when publishing to a broker that advertises the contracts/publish HAL relation:

1. GET <broker-base-url> — discovers the contracts/publish link
2. POST <discovered contracts/publish href> — actually publishes the pact

Any header passed via --custom-header 'Name: Value' is attached to request (1) but is silently dropped on request (2).

This breaks publishing to brokers sitting behind a gateway that authenticates via a custom header (e.g. Gravitee's x-api-key), since the actual publish call goes out unauthenticated and gets rejected with 401, even though the key is valid and the header is correctly supplied on the command line.

Steps to reproduce

1. Stand up a minimal HTTP server that:
   • Responds to GET / with a HAL document containing _links.pb:publish-contracts.href pointing at /contracts/publish
   • Logs the headers of every incoming request
2. Run:

   pact-broker publish ./pacts \
     --log-level debug \
     --consumer-app-version 0.0.0 \
     --broker-base-url http://localhost:9999 \
     --custom-header 'x-api-key: some-test-value'
   

3. Inspect the server logs for both the GET / and POST /contracts/publish requests.

Observed behavior

• GET / — includes x-api-key: some-test-value ✅
• POST /contracts/publish — header is missing ❌

Example captured headers:

// GET /
{
  "accept": "application/hal+json, application/json",
  "x-api-key": "TEST-KEY-VALUE",
  "user-agent": "pact-broker-cli/0.8.4"
}

// POST /contracts/publish
{
  "accept": "application/hal+json",
  "content-type": "application/json",
  "user-agent": "pact-broker-cli/0.8.4",
  "content-length": "1790"
  // x-api-key is absent
}

For comparison, running the same reproduction with --broker-token test-bearer-token instead of --custom-header correctly includes authorization: Bearer test-bearer-token on both requests.

Expected behavior

Headers supplied via --custom-header should be attached to every request the CLI makes as part of the publish flow, including any follow-on requests resolved via HAL links (contracts/publish, or any other discovered relation).

Real-world impact

Publishing to a Pact Broker fronted by an API gateway that authenticates via a custom header (e.g. Gravitee's x-api-key) fails with a 401 on the actual publish step, even though:

• the API key is valid (confirmed via direct requests to the broker using the same key), and
• the initial discovery request with the same header succeeds.

This makes --custom-header unusable for gateway-fronted brokers requiring a non-bearer, non-basic-auth header for authentication.

[nick-m-b]

Can confirm this is also occurring with the command create-or-update-pacticipant. During the initial GET calls, the custom header(s) are sent but the follow-up PATCH call does not forward the custom header(s)