The Content-Location HTTP header — async & long-running, RFC 9110, declared by 11 providers in the API Evangelist catalog.
Content-Location
Async & Long-Running IANA permanent response reached by regulation 2 spellings
A reference entry. The registry facts and catalog measurements below are complete; the written guidance for this header has not been authored yet.
Content-Location is async & long-running — Headers for work that does not finish inside the request: preference for async handling, polling locations, progress, retry timing.
The registry
Listed in the IANA HTTP Field Name Registry as a permanent entry. Defined in RFC 9110, Section 8.7: HTTP Semantics.
In the catalog
Declared by 11 providers across 215 published specification files in the API Evangelist catalog, where it appears as a response header — sent by the server.
It is spelled 2 different ways across those contracts — content-location, Content-Location. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.
Reached by regulation
This header is mandated: the law, or a technical standard the law makes binding, names it directly. It is visible in a published OpenAPI or AsyncAPI, so the catalog can count it.
Reached by these regulations
Catalogued at regulations.apievangelist.com, with the basis of each connection recorded rather than implied.
Governed by these rules
Machine-enforceable governance rules from rules.apievangelist.com that apply to this header when it appears in an OpenAPI.
OpenAPI Components Headers Error error
Utilizing the headers object in the centralized OpenAPI components library helps make headers reusable across API requests and responses
Guidance: Rate Limits →OpenAPI Components Headers Info info
Utilizing the headers object in the centralized OpenAPI components library helps make headers reusable across API requests and responses
Guidance: Rate Limits →OpenAPI Headers Hyphenated Pascal Case error
HTTP headers should follow Hyphenated-Pascal-Case naming convention for consistency and readability, such as Content-Type, X-Request-Id, or Accept-Language.
Guidance: Naming →