Skip to main content

​
Request headers KnoxCall does not forward

When KnoxCall proxies a request for you, a fixed set of request headers is withheld from your upstream. They describe the connection between your caller and KnoxCall, or they are instructions and credentials meant for KnoxCall itself, so they stop here. This page is the complete list of those headers. It applies to proxied traffic on every path:
  • your routes, in the cloud and on a self-hosted proxy
  • the AI Gateway (/v1/ai/...)
  • the ephemeral proxy (/v1/proxy)
  • inbound-webhook forwards (hooks.knoxcall.com)
The match is on the exact header name, in any letter case. There is no prefix rule behind this list: a header that merely starts with CF-, X-Forwarded- or X-KnoxCall- and is not named below is not withheld by it.
This page covers which headers are withheld. It is not a full description of how each path builds the request it sends to your upstream; that is on each path’s own page.

​
The list

​
Headers that address KnoxCall

These tell KnoxCall who is calling and which route to use. KnoxCall reads them and does not pass them on.

​
Headers a proxy in front of KnoxCall adds

A reverse proxy or CDN adds these to say where the request came from. They describe your caller’s connection to KnoxCall, not the request your upstream should see.

​
Headers Cloudflare adds

KnoxCall’s cloud edge runs on Cloudflare. These are the request headers Cloudflare itself can add on the way in.

​
Headers that belong to one connection

These describe a single network hop. KnoxCall opens its own connection to your upstream and sets what that connection needs itself.

​
Each path also keeps back its own credentials

The list above is shared by every path. Each path additionally keeps back the credential you used to authenticate to KnoxCall on that path:
  • Routes. Authorization and DPoP when the Authorization value is a KnoxCall access token (Bearer kc_… or DPoP kc_…), and X-Api-Key when it holds a KnoxCall credential. An Authorization or X-Api-Key that carries your upstream’s own credential is forwarded.
  • AI Gateway. Authorization, X-Api-Key, X-Knox-AI-Key and DPoP. The gateway authenticates you with these and supplies your provider’s credential from the route.
  • Ephemeral proxy. Authorization, every header beginning X-Knox-, and X-Api-Key when it holds a KnoxCall credential. See Invoke the ephemeral proxy.
  • Inbound-webhook forwards. Every header beginning X-Knox-. KnoxCall sets those itself to tell your receiver whether the signature verified. A delivery whose signature did not verify, where you have chosen to forward those, carries Content-Type and KnoxCall’s own X-Knox- headers and nothing else the sender sent.

​
Cloudflare Access credentials for your own upstream are forwarded

If your upstream sits behind Cloudflare Access, the headers your caller sends to authenticate to it are yours and are forwarded: CF-Access-Client-Id, CF-Access-Client-Secret and cf-access-token. Only the token Cloudflare Access adds on the way in to KnoxCall, Cf-Access-Jwt-Assertion, is withheld.

​
If your upstream needs one of these headers

There is no response header or error when a header is withheld. The request is forwarded without it.
  • On a route, including the route behind an AI Gateway agent, add the header to the route’s injected headers. A header the route injects is sent to your upstream even when its name is in one of the first three tables above; the route’s value is sent and the value your caller put in that header is not. There is no template helper for the caller’s IP address, so this suits a fixed value. The connection-level headers in the last table are always set by KnoxCall.
  • On the ephemeral proxy and on inbound-webhook forwards there are no injected headers, so a header on this list cannot be sent to the upstream on those paths. Send the value under a header name that is not on this list.