Proxy-Authentication-Info HTTP Header — Reference

What it does

Proxy-Authentication-Info is the proxy equivalent of Authentication-Info. After a client successfully authenticates with a proxy (via Proxy-Authorization), the proxy can include this header in the response to confirm mutual authentication and provide updated credentials for the next request.

Like Authentication-Info, it's primarily used with Digest authentication to give the client proof that the proxy knows the shared secret (rspauth) and to provide the next nonce (nextnonce) for the following request.

Syntax

Identical to Authentication-Info:

Proxy-Authentication-Info: <param>=<value>[, <param>=<value>]*

Example:

Proxy-Authentication-Info: nextnonce="newNonce789", qop=auth, rspauth="7a94f8c3b2e1d0f5a9c6b3e2d1f0", cnonce="0a4f113b", nc=00000001

Parameters

Parameter	Meaning
`nextnonce`	Nonce the client should use in its next `Proxy-Authorization`
`qop`	Quality of protection used in the exchange
`rspauth`	Server's response digest — proves the proxy knows the password
`cnonce`	Echoes the client nonce from the request
`nc`	Echoes the nonce count

Relationship to Authentication-Info

These two headers are exact mirrors, differing only in their target:

Header	Sent by	After authenticating with
`Authentication-Info`	Origin server	`Authorization` / `WWW-Authenticate`
`Proxy-Authentication-Info`	Proxy server	`Proxy-Authorization` / `Proxy-Authenticate`

Both serve the same mutual authentication purpose in Digest auth flows. Both are optional, rarely encountered in modern systems, and primarily relevant in legacy enterprise environments.

When you'll encounter this

Essentially the same scenarios as Authentication-Info but at the proxy level:

Corporate proxies using Digest authentication
Legacy enterprise network infrastructure
VoIP/SIP systems (which borrowed HTTP's Digest auth)

Modern systems have largely moved to TLS + Bearer tokens, making this header a niche artefact of the Digest authentication era.

Real-world example

Proxy Digest auth exchange with Proxy-Authentication-Info:

GET https://api.github.com/ HTTP/1.1
Proxy-Authorization: Digest username="corp_user",
  realm="Corporate Proxy",
  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  uri="https://api.github.com/",
  response="6629fae49393a05397450978507c4ef1"

HTTP/1.1 200 OK
Proxy-Authentication-Info: nextnonce="e66aa6d92b8f26b4e6a4e1c8ab34d6a3",
  qop=auth,
  rspauth="2206f89b3e71c41e9d4b7c42bbbf7b94"

The client verifies rspauth to confirm the proxy is legitimate. nextnonce is used in the next Proxy-Authorization header.

FAQ

Is Proxy-Authentication-Info required for proxy Digest auth to work?

No — it's optional. Proxy Digest auth can complete successfully without it. Proxy-Authentication-Info adds mutual authentication (the client can verify the proxy's identity) and nonce rotation (the proxy controls when nonces expire). Without it, the client can't verify the proxy's legitimacy but auth still succeeds.

Do I need to implement this in a modern application?

Almost certainly not. If you're building a new system, you won't be using Digest auth at the proxy level — TLS mutual auth, OAuth, or API keys are the modern equivalents. This header is relevant only when maintaining legacy enterprise infrastructure.

Fun fact

Proxy-Authentication-Info and Authentication-Info are among the most obscure headers in common HTTP implementations — most HTTP server libraries don't even implement them, and virtually no developer encounter them in a normal career. They're survivors from a brief window (roughly 1997–2005) when Digest authentication looked like the future of HTTP security, before TLS became both cheap and ubiquitous. Today they exist mainly to complete the symmetry of the HTTP auth model: every origin auth header has a proxy counterpart, and Authentication-Info is no exception.

Proxy-Authentication-Info auth response