Description
HTTP header names are case-insensitive. Defining token and Token as different headers on the same request can falsely suggest that they carry separate values.
Potential impact
Documentation and generated clients may manage the same header twice or assign conflicting meanings, causing request integration problems.
Remediation
Maintain one consistent definition for each header applied to a request. If separate values are needed, use distinct names recognized by the actual API. Distinguish similar entries in a reusable definition map from duplicates applied together to one request.
Examples
These are OpenAPI 3.0 path-level parameter excerpts. They omit info and the actual operations and do not represent a complete authentication configuration.
Before
{
"openapi": "3.0.0",
"paths": {
"/": {
"parameters": [
{
"name": "token",
"in": "header",
"schema": {
"type": "string"
}
},
{
"name": "Token",
"in": "header",
"schema": {
"type": "string"
}
}
]
}
}
}
After
{
"openapi": "3.0.0",
"paths": {
"/": {
"parameters": [
{
"name": "token",
"in": "header",
"schema": {
"type": "string"
}
},
{
"name": "username",
"in": "header",
"schema": {
"type": "string"
}
}
]
}
}
}
The before names token and Token identify the same HTTP header. The after username header is appropriate only if the server actually accepts a separate username value. If both definitions mean the same token, remove the second one instead.