HTTP 510 Not Extended – Free, Online, Private

What HTTP 510 means

510 says the server needs an extension to the request, described in the body, before it will fulfill it. The client may resend with that extension. RFC 2774 defined this for mandatory HTTP extensions. It is rarely used. A server that requires a private header should think hard before using 510 instead of a documented 400. Clients will not understand 510 unless they implement the extension mechanism.

510 Not Extended belongs to the 5xx server error 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 510

When you see HTTP 510 Not Extended, stop on that exact status line. 510 Not Extended means the server requires a request extension the client did not send. The trace that usually produces it: A mandatory extension was not present on the request. The 5xx server error 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.

Return 510 only if you are actually using the HTTP extension framework and the client omitted a mandatory extension. For a missing API key, use 401. For a missing required header in your own API, use 400 and name the header. 510 without a body that describes the extension is useless.

How to fix HTTP 510

To fix HTTP 510, change the condition that made the server choose Not Extended. If you understand the extension named in the body, add it and retry once. If you do not, stop. Do not guess a header. Once, with the required extension. Not without it. If the log line is a different code, leave this page. The mix-up people make with 510 is this one: 401 is a missing credential. 400 is a missing field you defined. 426 is a protocol upgrade. 510 is a missing HTTP extension in the RFC 2774 sense.

• The body failed to describe the extension, so the client could not retry correctly.
• An API used 510 for a missing custom header and every generic client failed closed.
• A proxy stripped the extension and the origin answered 510.

An access log that only stores 510 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 510 Not ExtendedHTTP/1.1 510 Not Extended
Content-Type: text/plain

This service requires an extension the request did not include.

The body is supposed to tell the client which extension to add. If you cannot name it clearly, you should not be using 510. The retry includes the extension. An unchanged retry fails. Most public APIs will never emit this status.

What the client should do

If you understand the extension named in the body, add it and retry once. If you do not, stop. Do not guess a header.

Do not cache 510 as the resource.

Once, with the required extension. Not without it.

Codes people confuse with HTTP 510

401 is a missing credential. 400 is a missing field you defined. 426 is a protocol upgrade. 510 is a missing HTTP extension in the RFC 2774 sense.