Headers properties should be case insensitive.

[Maks3w]

HTTP Header names are case insensitive. Swagger specification enforce to be case sensitive all field names without exceptions.

All field names in the specification are case sensitive.

Parameter names are case sensitive.

The specification should clarify headers names are case insensitive and must be validated in that way.

So the following schema:

"parameters": [
  {
    "name": "petId",
    "in": "heaer",
    "type": "string"
  }
]

"headers": {
  "X-Rate-Limit-Limit": {
    "description": "The number of allowed requests in the current period",
    "type": "integer"
  }
}

Should be validate these headers as valid headers:

headers: [
  "PETID",
  "x-rate-limit-limit"
]

[jharmn]

From a spec standpoint, there's really no issue. This is more around the processing of requests, which is out of the scope of the spec.
Are there multiple places in the spec where a header is referenced (I couldn't think of it, but maybe I'm missing it)? Even if so, the intent of case sensitivity rules in RFC7230 is in regards to processing requests.
IMO adding this exception to the spec simply adds unnecessary complexity to parsers. The spec should be case consistent any any references.

[webron]

There's an edge case where you can define two header parameters with the same names only with different cases. While valid for other parameter types, it's conceptually invalid for header parameters. Don't think this needs to be addressed by the spec though, it's more of a user error in that case. Just putting it on the table here.

[whitlockjc]

I'm on the fence about this. On the one hand, I agree with @Maks3w because most libraries I've ever used seem to work this way. On the other hand, I agree @jasonh-n-austin that consistency is more important than anything. I just don't see why anyone would use PetId in one place and petid or any other permutation elsewhere. Regardless of "who wins", in the end this is really a tooling thing.

[jharmn]

I agree with @webron that making uniqueness case-insensitive when specifying parameters makes some sense, but probably isn't that high priority.

I guess I could see some argument that if you're using the OpenAPI Spec to validate incoming requests, case sensitivity could be an issue. However, that's still not a spec issue, that's on whatever implementation isn't following RFC7230 on header handling.

Perhaps a 'caveat' in the spec might be useful to guide implementers.

[casualjim]

I think it should be spec'ed that headers need to be canonicalized. It should at the very least trigger a validation warning by the tools, consistently.

[IndunilRathnayake]

Hi @jharmn,

Would like to know the conclusion of this discussion. We have the same concern where the java-library in [1] has been used, which is built based on the OpenAPI specification.

As per the Hypertext Transfer Protocol specification in [2] :

4.2 Message Headers
Field names are case-insensitive.

As per the OpenAPI specification v3.0 in [3] :

All field names in the specification are case sensitive. This includes all fields that are used as keys in a map, except where explicitly noted that keys are case insensitive.

header - Custom headers that are expected as part of the request. Note that RFC7230 states header names are case insensitive. 

So that the OpenAPI specification not expecting to validate header names, case-sensitively. Rather stating to validate case-insensitively. Please verify.

[1] https://bitbucket.org/atlassian/swagger-request-validator/src/swagger-request-validator-2.3.0/
[2] https://tools.ietf.org/html/rfc2616#section-4.2
[3] https://swagger.io/specification/

Thanks
Indunil

[handrews]

Headers have been noted as case-insensitive in the spec for a while, and issue #2785 tracks adding a top-level comment, so I'm closing this issue in favor of that one.