이 문서는 아직 자원 봉사자들이 한국어로 번역하지 않았습니다. 참여해서 번역을 마치도록 도와 주세요!
English (US)의 문서도 읽어보세요.
The HTTP 204 No Content success status response code indicates that the request has succeeded, but that the client doesn't need to go away from its current page. A 204 response is cacheable by default. An ETag header is included in such a response.
The common use case is to return 204 as a result of a PUT request, updating a resource, without changing the current content of the page displayed to the user. If the resource is created, 201 Created is returned instead. If the page should be changed to the newly updated page, the 200 should be used instead.
Status
204 No Content
Specifications
| Specification | Title |
|---|---|
| RFC 7231, section 6.3.5: 204 No Content | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
Browser compatibility
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
| Desktop | Mobile | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | Android webview | Chrome for Android | Edge Mobile | Firefox for Android | Opera for Android | iOS Safari | Samsung Internet | |
| Basic support | Chrome Full support Yes | Edge Full support Yes | Firefox Full support Yes | IE Full support Yes | Opera Full support Yes | Safari Full support Yes | WebView Android Full support Yes | Chrome Android Full support Yes | Edge Mobile Full support Yes | Firefox Android Full support Yes | Opera Android Full support Yes | Safari iOS Full support Yes | Samsung Internet Android Full support Yes |
Legend
- Full support
- Full support
Compatibility notes
- Although this status code is intended to describe a response with no body, servers may erroneously include data following the headers. The protocol allows user agents to vary in how they process such responses (discussion regarding this specification text can be found here). This is observable in persistent connections, where the invalid body may include a distinct response to a subsequent request.
Apple Safari rejects any such data. Google Chrome and Microsoft Edge discard up to four invalid bytes preceding a valid response. Firefox tolerates in excess of a kilobyte of invalid data preceding a valid response.