HTTP 203 Non-Authoritative Information – Free, Online, Private

What HTTP 203 means

203 says the request succeeded and the body is not the origin's original representation. A proxy converted the format, translated the document, or otherwise transformed it. The status warns the client that the payload may differ from what the origin would have sent. It is rare on APIs you control, because you are the origin.

203 Non-Authoritative Information belongs to the 2xx successful class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 203

When you see HTTP 203 Non-Authoritative Information, stop on that exact status line. 203 means a transforming proxy changed the representation the origin sent. The trace that usually produces it: A translating proxy rewrote HTML and marked the result non-authoritative. The 2xx successful class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

A proxy returns 203 when it has transformed the origin's 200 and wants the client to know. Origins should not use 203 to mean 'the data is a bit stale' or 'this is a summary'. Those are 200 with cache headers, or a different URL.

How to fix HTTP 203

To fix HTTP 203, change the condition that made the server choose Non-Authoritative Information. Accept 203 as success if the content type is one you can read. Do not fail the call only because the code is not 200. If you need bit-exact origin content, 203 is the signal that you do not have it. Retrying will not produce the origin bytes if the proxy transforms every response. Changing the request so it is not transformed is the fix. If the log line is a different code, leave this page. The mix-up people make with 203 is this one: It is not 206, which is a byte range of the real representation, and it is not an error. The request succeeded.

• An API gateway returned 203 for an ordinary JSON pass-through, and clients started ignoring the body.
• A client treated 203 as an error because it only allowed 200.
• The origin itself sent 203, so the warning no longer means a proxy touched the body.

An access log that only stores 203 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 203 Non-Authoritative InformationHTTP/1.1 203 Non-Authoritative Information
Content-Type: text/html
Warning: 214 Transformation Applied

<html>...</html>

The body is usable. The status and the Warning header say it was transformed. If your client needs the origin bytes, it has to request them in a way the proxy will not transform, which is uncommon and proxy-specific.

What the client should do

Accept 203 as success if the content type is one you can read. Do not fail the call only because the code is not 200. If you need bit-exact origin content, 203 is the signal that you do not have it.

Caches may store 203 under the usual rules. A later request might then receive the transformed copy. That is a reason to vary on the headers that caused the transformation.

Retrying will not produce the origin bytes if the proxy transforms every response. Changing the request so it is not transformed is the fix.

Codes people confuse with HTTP 203

It is not 206, which is a byte range of the real representation, and it is not an error. The request succeeded.