203 Non-Authoritative Information: When Metadata Comes from a Third Party
ETag, Last-Modified, or Cache-Control) comes from a local cache or a third-party intermediary, not directly from the origin server. The response body itself may still be accurate, but the headers cannot be trusted as authoritative.
When Does 203 Occur?
This code is typically generated by:
- Proxy servers – when they serve a cached response but cannot verify that the metadata matches the origin.
- CDN edge nodes – when they return a stale copy with headers that may differ from the origin.
- Transforming proxies – that modify the response content but leave the original metadata intact.
It is rarely used directly by application developers. Most web servers (Apache, Nginx) do not emit 203 by default; it's an intermediate response.
Example Scenario
| Step | Direction | HTTP Message |
|---|---|---|
| 1 | Client → Proxy | GET /resource HTTP/1.1 |
| 2 | Proxy → Origin | GET /resource HTTP/1.1 |
| 3 | Origin → Proxy | HTTP/1.1 304 Not Modified |
| 4 | Proxy → Client | HTTP/1.1 203 Non-Authoritative Information |
Here, the proxy returns cached content with its own ETag, but warns the client that the metadata is not authoritative.
Why It Matters to Developers
If you are building a client that relies on headers like ETag for caching or conditional requests, a 203 response tells you that those headers may be outdated or inaccurate. You should treat them with caution:
- Do not use
ETagfrom a 203 response for futureIf-MatchorIf-None-Matchrequests. - Do not cache the response based on
Cache-Controlfrom a 203, as it may not reflect the origin's policy. - If possible, re‑validate with the origin server to get authoritative metadata.
When to Use 203 in Your Own APIs
Most API developers never need to send 203. If you are building a proxy or gateway, you may use it to indicate that you are returning transformed or cached data. For most REST APIs, 200 OK is sufficient.
Frequently Asked Questions
Is 203 an error?
No, it's a success code (2xx). It means the request was processed successfully, but the headers are not authoritative. The content itself is still valid.
How is 203 different from 200 OK?
200 OK means the response (headers and body) comes directly from the origin server and is authoritative. 203 means the body may be correct, but the headers come from a non‑authoritative source.
Can browsers handle 203 correctly?
Yes, modern browsers treat 203 similarly to 200 in terms of rendering the content. However, they may disable certain optimizations based on the non‑authoritative headers.