Reset Content
ActiveHTTP 205 Reset Content tells the client the server fulfilled the request and the user agent SHOULD reset the document view that sent it. Defined in RFC 9110 §15.3.6. The response MUST NOT include a body. Think: 'form submitted successfully — now clear the form fields.'
Description
The 205 Reset Content status code indicates that the server has successfully fulfilled the request and desires that the user agent reset the document view which caused the request to be sent. This code allows the server to indicate that the action has been completed and the client should clear the form or reset the view to its original state, ready for new input.
The critical constraint: a server MUST NOT generate content in a 205 response. The Content-Length header, if present, MUST be 0, or the Transfer-Encoding must indicate zero-length. This makes 205 unique among success codes — it's an affirmative response that explicitly forbids a response body. Any intermediary receiving a 205 with content SHOULD strip it before forwarding.
The distinction from 204 No Content is subtle but important. 204 means 'done, carry on as you were' — the view doesn't change, the page stays put. 205 means 'done, now reset your view' — clear the form fields, reset the editor, return the UI to its initial state. It's the difference between saving a document (204) and submitting a form that should be cleared for the next entry (205).
205 is rarely seen in modern web development because single-page applications handle form resets client-side via JavaScript. The browser behavior for 205 was designed for server-rendered multi-page applications where the server needed to instruct the browser to clear form state without navigating to a new page. However, it remains semantically correct and useful in APIs that want to explicitly signal 'reset your input state.'
Browser support for the reset behavior is inconsistent. While all browsers accept 205 as a success code, not all actually clear form fields as the spec intends. In practice, most modern usage is in REST APIs where the semantic meaning ('action complete, reset your input') is handled by client application logic rather than browser-native behavior.
Examples
POST /api/feedback HTTP/1.1
Host: app.example.com
Content-Type: application/json
Authorization: Bearer token123
{"rating": 5, "comment": "Great service!", "category": "support"}HTTP/1.1 205 Reset Content
Content-Length: 0
Date: Mon, 15 Jan 2024 10:30:00 GMTPOST /api/inventory/items HTTP/1.1
Host: warehouse.example.com
Content-Type: application/json
{"sku": "WH-4421", "name": "Widget A", "quantity": 500, "location": "Aisle 7B"}HTTP/1.1 205 Reset Content
Content-Length: 0
X-Items-Added-Today: 47
Date: Mon, 15 Jan 2024 14:22:00 GMTPOST /api/channels/general/messages HTTP/1.1
Host: chat.example.com
Content-Type: application/json
Authorization: Bearer user-token
{"text": "Hello everyone!", "attachments": []}HTTP/1.1 205 Reset Content
Content-Length: 0
Date: Mon, 15 Jan 2024 16:05:00 GMTEdge Cases
- •A 205 response MUST NOT contain a body. If Content-Length is present, it MUST be 0. Servers that accidentally include content violate the spec and intermediaries SHOULD strip it.
- •205 does not mean 'navigate away' — it means 'reset the current view in place.' If you want the client to go somewhere else, use 303 See Other with a Location header.
- •Browsers inconsistently implement the form-reset behavior. Chrome and Firefox may not actually clear form fields on 205. Don't rely on browser-native 205 behavior — handle it in JavaScript.
- •Unlike 201 Created, 205 cannot include a Location header pointing to a new resource. If the client needs to know the created resource's URL, use 201 instead.
- •For APIs: 205 is a stronger signal than 204. Returning 205 tells the client 'I expect you to reset your input state' — it's a directive, not just an acknowledgment.
- •Transfer-Encoding: chunked with a zero-length body (empty final chunk) is valid for 205. The constraint is zero content, not zero headers.
- •Some HTTP/2 implementations treat 205 identically to 204 at the frame level since neither carries a DATA frame. The semantic difference exists only at the application layer.
When You'll See This
- →Data entry clerk submitting inventory records one after another — each submission clears the form for the next item
- →Feedback form on a kiosk — after submission, the form resets for the next customer
- →Chat application — message sent successfully, clear the compose input
- →Survey or quiz — answer submitted, reset the question area for the next one
- →Point-of-sale terminal — transaction complete, clear the screen for the next sale
- →Bulk import tool — row validated and accepted, clear the input row for the next entry
- →Password change form — credentials updated, clear all password fields
Implementation References
| Language | Constant |
|---|---|
| Go | http.StatusResetContent |
| Rust | http::StatusCode::RESET_CONTENT |
| Python | http.HTTPStatus.RESET_CONTENT |
| Node.js | http.STATUS_CODES[205] |
| .NET | HttpStatusCode.ResetContent |
| Java | HttpURLConnection.HTTP_RESET |
| PHP | Response::HTTP_RESET_CONTENT (Symfony) |
| Ruby | :reset_content (Rack) |
History
Introduced in HTTP/1.1 (RFC 2068, 1997) alongside 204 No Content. Designed for the era of server-rendered HTML forms where browsers needed explicit server instructions to clear form state without performing a full page navigation. The original use case was data entry workflows — submit a record, server says '205', browser clears the form for the next entry. As web development shifted to client-side frameworks (jQuery, then React/Vue/Angular), the browser-native reset behavior became irrelevant since SPAs manage form state in JavaScript. RFC 9110 (2022) maintained the status code with clarified body constraints but acknowledged its diminished practical usage. Despite being rare in the wild, 205 remains the semantically correct response when a server wants to explicitly instruct the client to reset its input view.
Related Status Codes
Related Headers
FAQ
What is the difference between HTTP 204 No Content and 205 Reset Content?
Both indicate success with no response body, but they carry different instructions to the client. 204 means 'action succeeded, no further action needed' — the client continues displaying whatever it was showing. 205 means 'action succeeded, now reset your document view' — the client should clear form fields, reset editors, or return the UI to its initial input state. Think of 204 as 'save' (document stays open) and 205 as 'submit and clear' (form goes blank for next entry). In REST APIs, 204 is used for updates where the client already has the data, while 205 signals the client should prepare for new input.
Can a 205 Reset Content response have a body?
No. RFC 9110 §15.3.6 explicitly states that a server MUST NOT generate content in a 205 response. If Content-Length is present, it must be 0. If Transfer-Encoding is used, it must indicate zero length (empty chunked body). This is a hard constraint, not a recommendation. Any intermediary (proxy, CDN) that receives a 205 with content SHOULD strip the body before forwarding. If you need to return data alongside a success response, use 200 OK instead and handle the form reset in client logic.
Why is HTTP 205 rarely used in modern web applications?
205 was designed for server-rendered HTML form workflows where the browser needed an explicit signal to clear form state without navigating. Modern single-page applications (React, Vue, Angular) manage form state entirely in JavaScript — when a submission succeeds (200 or 204), the client-side code decides whether to clear the form, show a success message, or navigate elsewhere. The browser's native 205 form-reset behavior is also inconsistently implemented. However, 205 remains semantically valid in REST APIs as a way to explicitly communicate 'reset your input state' — it's just that most API clients handle this logic regardless of whether they receive 204 or 205.