HTTP 510 Not Extended
Quick reference
| Code | 510 |
|---|---|
| Name | Not Extended |
| Category | 5xx Server Error |
| Spec | RFC 2774 §7 |
| In practice | Extremely rare — RFC 2774 not deployed |
What 510 means
HTTP 510 Not Extended is returned when an HTTP server requires a client to include a specific HTTP extension declaration in its request — and that declaration is missing. The code was defined by RFC 2774 "An HTTP Extension Framework," published in February 2000 as an Experimental RFC.
The premise of RFC 2774 was that HTTP could be extended with new headers and behaviors, and that clients could signal which extensions they support using Man: (mandatory extension) and Opt: (optional extension) headers. A server requiring a mandatory extension that the client did not declare would respond with 510 to inform the client that the request cannot be processed without that extension.
Like RFC 2295 (TCN, related to 506), RFC 2774 was never adopted by mainstream HTTP implementations and was never advanced to standards track. The modern HTTP extension mechanisms — Upgrade:, Alt-Svc:, HTTP/2 SETTINGS frames, HTTP/3 QUIC transport parameters — replaced the need for the RFC 2774 approach.
RFC 2774 extension framework
RFC 2774 defined three request headers for extension negotiation:
Man: (mandatory extension) — declares a required extension. The server must process the extension or return an error. Example:
GET /resource HTTP/1.1 Host: example.com Man: "http://example.com/ext/myextension"; ns=10 10-Ext-Header: value
The ns=10 assigns a namespace prefix. Extension headers for this extension are prefixed with 10-. If the server does not support http://example.com/ext/myextension as a mandatory extension, it must return a 501 Not Implemented (if it does not understand extensions at all) or 510 Not Extended (if it understands the framework but requires a different extension).
Opt: (optional extension) — declares an extension the server may use but is not required to. The server can ignore Opt: extensions without returning an error. If an Opt: extension is understood and used, the server includes a Ext: response header confirming it.
C-Man: and C-Opt: — same semantics as Man/Opt but scoped to hop-by-hop (proxy) rather than end-to-end processing.
510 is specifically the error for "the server requires an extension via Man: that was not present in the request." The response body is supposed to identify which extension is required, allowing the client to add it and retry.
Why RFC 2774 was abandoned
The HTTP extension framework of RFC 2774 failed to gain adoption for several reasons. The namespace-based prefix mechanism (ns=10, 10-Header:) was verbose and awkward compared to simply defining new headers. Proxy handling of C-Man: extensions added implementation complexity without clear benefit. The framework required both client and server to implement the extension negotiation layer before any actual functionality could be used.
Meanwhile, the HTTP working group found that most useful HTTP extensions could be deployed without a formal framework: new headers could be registered with IANA, connection upgrades used Upgrade:, and protocol negotiation moved to TLS ALPN (Application-Layer Protocol Negotiation). By the time HTTP/2 was standardized in 2015 (RFC 7540) and HTTP/3 in 2022 (RFC 9114), the RFC 2774 approach was entirely superseded.
The 510 status code remains in the IANA registry and in modern HTTP specifications (RFC 9110 does not define it but does not remove it either) as a legacy registration.
When you might actually see 510
Encountering a genuine 510 in production almost certainly means one of three things: a custom HTTP extension layer (e.g. a bespoke enterprise middleware stack) that requires proprietary extension headers before processing requests; a misconfigured server or proxy that erroneously emits 510 for unrelated conditions (a bug, not an intentional 510); or test and research environments deliberately implementing RFC 2774 for academic or compatibility purposes.
If you see 510 in logs or monitoring, examine the response body for an extension URL or description. If the response body does not clearly identify a required extension, it is likely a server bug that should be filed against the software generating the 510.
510 vs related codes
| Code | Meaning | Difference |
|---|---|---|
| 510 | Required HTTP extension missing (RFC 2774) | — |
| 501 Not Implemented | Server does not recognize the method or extension | 501 = unknown; 510 = known but not included in request |
| 426 Upgrade Required | Client must switch protocols (e.g. to HTTPS) | Protocol version upgrade, not an HTTP extension |
| 400 Bad Request | Malformed request syntax | Generic; does not identify a specific required extension |
Frequently asked questions
Is 510 defined in RFC 9110?
No. RFC 9110 (the current HTTP semantics standard) does not define 510. The code originates from RFC 2774, which remains published as an Experimental RFC. The 510 entry in the IANA HTTP Status Code Registry points to RFC 2774 as its source.
What should a client do after receiving 510?
The client should read the response body to identify the required extension, add the appropriate Man: header with the extension URI, and retry the request. In practice, since RFC 2774 extensions are vanishingly rare, receiving a 510 most likely indicates a server misconfiguration — escalate to the API provider.
Can I use 510 in my own API for a different purpose?
Technically the status code is available, but repurposing registered codes for non-standard semantics creates confusion for clients and monitoring tools. Use 400 Bad Request (missing required header) or 422 Unprocessable Content (semantic validation failure) for cases where a required element is missing from the request.
Is 510 cacheable?
No. A 510 response indicates a request-level requirement the client must fulfill, which is session- and context-dependent. Caching and replaying a 510 to different clients would be incorrect behavior.