HTTP 205 Reset Content

What 205 Reset Content means

205 was designed for one workflow: a data entry clerk filling in the same form repeatedly. Submit a record, the fields blank themselves, type the next one. The status is an instruction to the user agent about its own UI, nearly unique among status codes.

No mainstream browser has ever implemented that reset. A form posted to an endpoint returning 205 does not clear itself, and since the response cannot contain a body there is nothing to render either. In a single-page app the client owns form state directly and does not need the server to ask, which removes the last reason to use it.

What the spec says

RFC 9110 §15.3.6 defines 205 and states that a server MUST NOT generate content in a 205 response. That MUST NOT is the practical trap: earlier HTTP drafts went back and forth on how a 205 should be framed, and some servers still emit a Content-Length greater than zero or a chunked body, a violation that confuses HTTP/1.1 keep-alive handling. The spec says nothing about how the user agent should perform the reset, part of why nobody implemented it consistently.

What actually causes it

In practice 205 shows up in two places: very old form-driven intranet applications, and code where someone picked the status by name. The second bites. An endpoint returning 205 to a fetch caller gives the JavaScript nothing to work with, because the body must be empty and no browser performs the reset. If the intent is “the write worked and there is nothing to say”, 204 is the code every client handles. If it is “here is the fresh state”, return 200. The genuinely broken case is a server emitting 205 with a body: some HTTP/1.1 stacks read the leftover bytes as the start of the next response on a keep-alive connection, corrupting an unrelated request.

How to debug it

The only thing worth checking is framing. Confirm the response has zero content and that the connection survives a second request on it:

curl -sv -o /dev/null -X POST -d 'field=value' https://forms.example.com/entry \
https://forms.example.com/entry 2>&1 | grep -iE '^(< HTTP|< content-|\* Re-using)'

Passing the URL twice reuses the connection, so a botched 205 surfaces as a parse error or unexpected close on the second request rather than the first. A content-length above zero means the server violates the MUST NOT; fix that first. Beyond framing there is nothing to debug. No browser reacts to the code, so if the expected behaviour is a cleared form the reset belongs on the client.

Working examples

curl

# Check that the 205 is framed correctly and does not poison keep-alive.
curl -sv -o /dev/null \
  -X POST -d 'field=value' \
  https://forms.example.com/entry https://forms.example.com/entry 2>&1 \
  | grep -iE '^(< HTTP|< content-length|\* Re-using|\* Connection)'

# A compliant 205 shows no content-length above zero and reuses the connection.

Python (requests)

import requests

s = requests.Session()  # keep-alive, so framing bugs surface on the second call
resp = s.post("https://forms.example.com/entry", data={"field": "value"}, timeout=10)

print(resp.status_code, len(resp.content))  # 205 0
if resp.status_code == 205 and resp.content:
    print("spec violation: 205 MUST NOT carry content")

# Second request over the same connection - a bad 205 breaks here, not above.
print(s.get("https://forms.example.com/entry", timeout=10).status_code)

Node (fetch)

const res = await fetch("https://forms.example.com/entry", {
  method: "POST",
  body: new URLSearchParams({ field: "value" }),
});

console.log(res.status, res.ok); // 205 true
const text = await res.text();
if (text.length) console.warn("205 returned a body; this violates RFC 9110");

// No browser clears the form for you. Do it yourself and return 204 server-side.
if (res.status === 205) document.querySelector("form")?.reset();

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.

205 Reset Content

Common causes at a glance