[BUG][GO] Generated client does not use `http.Header.Set` for request headers

[Wuchieh]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• Have you [tested with the latest master](https://github.com/OpenAPITools/openapi-generator/wiki/FAQ#how-to-test-with-the-latest-master-of-openapi-generator) to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request

Description

The generated Go client directly modifies the underlying http.Header map when setting request headers instead of using http.Header.Set.

The current generated code is similar to:

headers := http.Header{}
for h, v := range headerParams {
    headers[h] = []string{v}
}
localVarRequest.Header = headers

This bypasses the header name canonicalization performed by http.Header.Set.

For example, a header defined as x-api-key may be stored as x-api-key instead of the canonicalized X-Api-Key.

This can also result in logically equivalent HTTP header names being stored as different map keys when they differ only in casing.

The generated client should use http.Header.Set when assigning request headers so that header names are canonicalized consistently.

openapi-generator version

Latest master as of 2026-08-24.

The issue is present in the Go client generator template:

modules/openapi-generator/src/main/resources/go/client.mustache

OpenAPI declaration file content or url

Minimal OpenAPI specification:

openapi: 3.0.3
info:
  title: Header Test API
  version: 1.0.0

paths:
  /test:
    get:
      parameters:
        - name: x-api-key
          in: header
          required: true
          schema:
            type: string
      responses:
        '200':
          description: OK

Generation Details

Generate a Go client using the Go generator.

For example:

java -jar openapi-generator-cli.jar generate \
  -i openapi.yaml \
  -g go \
  -o ./generated

Steps to reproduce

1. Create the OpenAPI specification above.
2. Generate a Go client using the go generator.
3. Inspect the generated request code.
4. Observe that request headers are assigned directly to the underlying http.Header map:

headers[h] = []string{v}

5. Compare this with using the http.Header.Set API:

headers.Set(h, v)

Actual output vs expected output

Actual:

The generated client directly modifies the underlying http.Header map:

headers[h] = []string{v}

This bypasses http.Header's canonicalization behavior.

Expected:

The generated client should use:

headers.Set(h, v)

This ensures that request header names are handled using the standard net/http header API and are canonicalized consistently.

Related issues/PRs

No directly related issue or PR was found after searching the existing OpenAPI Generator issues and pull requests.

There are other issues related to HTTP headers, but none found that address the Go client's direct manipulation of the underlying http.Header map.

Suggest a fix

Use http.Header.Set when populating request headers in the Go client template.

Replace:

for h, v := range headerParams {
    headers[h] = []string{v}
}

with:

for h, v := range headerParams {
    headers.Set(h, v)
}

This allows the standard library to perform header name canonicalization and preserves the expected semantics of the http.Header API.

A regression test should also be added to ensure that generated Go clients correctly handle request header names.