510 Not Extended
Server error response defined by RFC 2774 §7.
Last updated July 27, 2026
Common causes at a glance
- A legacy server implementing RFC 2774 mandatory extension declarations
- An application choosing 510 arbitrarily for a policy or precondition failure
- A middlebox reusing the code for a proprietary requirement
- Test fixtures enumerating every value in the IANA registry
Reproduce it
curl -i -H 'Man: http://www.example.org/ext/rewrite; ns=15' https://legacy.example.com/What 510 Not Extended means
RFC 2774 proposed a general mechanism for bolting extensions onto HTTP. A
request would declare which extensions it was using via Man or
Opt header fields naming a URI, and a server could demand that a client
declare a mandatory extension before it would serve a resource. 510 was the refusal:
“you did not declare the extension this resource requires, and here is what you need”.
The framework never gained traction. The extension points HTTP already had — new header fields, new methods, new media types — turned out to be sufficient, and the mandatory-extension model sat badly with the principle that intermediaries forward what they do not understand. The mechanism was retired rather than repaired, and 510 went with it.
What the spec said
RFC 2774 §7 defined 510 and specified that the server should send back all the information necessary for the client to issue an extended request, with the client permitted to retry if the response described extensions it could satisfy. RFC 2774 was reclassified to Historic by the IETF’s status change of HTTP experiments, and the IANA HTTP Status Code Registry now lists 510 as “Not Extended (OBSOLETED)”. No current specification requires any client or server to understand it, and it appears in no HTTP/1.1, HTTP/2, or HTTP/3 core document.
Where you might still see it
Effectively nowhere in production. The realistic sighting is an internal service that needed a code meaning “your request is missing something mandatory” and reached for 510 because it sounded right. That is worth correcting: a request missing a required declaration is a client error, so 400 with a problem-details body, or 428 where a precondition is genuinely required, communicates far more. The other sighting is in test suites that enumerate the full registry, which is why 510 turns up in libraries that will never emit it.
How to debug it
There is little to debug client-side, because no modern client knows how to satisfy the requirement. Confirm what you received and who sent it:
curl -sS -D - https://legacy.example.com/ | head -30
Read the body: RFC 2774 required the server to describe the extension it wants, so if the body names one you know what the server thinks it is asking for. The practical resolution is server-side. If you control the server, stop emitting 510 and pick a code from the current registry that describes the real condition. If you do not, treat the response as a hard failure rather than something to retry. The status code reference is a quick way to find a code that fits.
Working examples
curl
# Send an RFC 2774 mandatory extension declaration and read the full response.
curl -sS -D - \
-H 'Man: http://www.example.org/ext/rewrite; ns=15' \
-H '15-Policy: strict' \
https://legacy.example.com/ | head -30
# Compare with an ordinary request; a 510 that only appears with Man: is genuine.
curl -sSI https://legacy.example.com/
Python (requests)
import requests
resp = requests.get(
"https://legacy.example.com/",
headers={"Man": "http://www.example.org/ext/rewrite; ns=15"},
timeout=10,
)
print(resp.status_code, resp.headers.get("Server"))
if resp.status_code == 510:
# Obsolete: no client can negotiate this. Treat as a permanent failure.
print("server demands an RFC 2774 extension:", resp.text[:300])
Node (fetch)
const res = await fetch("https://legacy.example.com/", {
headers: { Man: "http://www.example.org/ext/rewrite; ns=15" },
});
console.log(res.status, res.headers.get("server"));
if (res.status === 510) {
// Historic code. Do not retry; there is nothing to negotiate.
console.error("RFC 2774 Not Extended:", (await res.text()).slice(0, 300));
}Reference and tooling
The authoritative list of assigned status codes is theIANA HTTP Status Code Registry. For a searchable copy with the semantics summarised, use theHTTP status code reference on this site. To see exactly what a server is sending, theheader inspector shows the raw status line and response headers, and thecurl builder assembles the request flags for you.
Other 5xx codes
- 500 Internal Server Error
- 501 Not Implemented
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
- 505 HTTP Version Not Supported
- 506 Variant Also Negotiates
- 507 Insufficient Storage
- 508 Loop Detected
- 511 Network Authentication Required
- 520 Web Server Returns an Unknown Error
- 521 Web Server Is Down
- 522 Connection Timed Out
- 523 Origin Is Unreachable
- 524 A Timeout Occurred
- 525 SSL Handshake Failed
- 526 Invalid SSL Certificate
- 530 Unable to Resolve Origin Hostname