| Kode status HTTP | Arti kode status |
|---|
| 100 | Sisi klien harus terus mengirim permintaan. Tanggapan sementara ini digunakan untuk memberitahu sisi klien bahwa beberapa permintaannya telah diterima oleh server dan belum ditolak. Sisi klien harus terus mengirim sisanya permintaan, atau abaikan tanggapan jika permintaan telah selesai. Server harus mengirim tanggapan akhir kepada sisi klien setelah permintaan selesai. |
| 101 | Server telah memahami permintaan klien dan akan memberitahu sisi klien melalui header Upgrade untuk menggunakan protokol yang lain untuk menyelesaikan permintaan. Setelah mengirimkan baris kosong terakhir dalam tanggapan, server akan berpindah ke protokol yang ditentukan dalam header Upgrade. Langkah yang sama hanya harus diambil saat pergantian ke protokol baru lebih bermanfaat. Contohnya, pergantian ke versi HTTP baru memiliki keunggulan di atas versi lama, atau pergantian ke real}}-waktu dan protokol sinkron untuk mengirimkan sumber daya yang mengambil keuntungan dari fitur ini. |
| 102 | Kode status yang diperpanjang oleh WebDAV (RFC 2518) menunjukkan bahwa pemrosesan akan terus berlanjut. |
| 200. | Permintaan sukses, dan header tanggapan yang diinginkan atau badan data dikembalikan bersama dengan tanggapan. |
| 201 | Permintaan telah terpenuhi, dan sumber daya baru telah dibuat berdasarkan persyaratannya, dan URI-nya telah dikembalikan bersama dengan header Lokasi. Jika sumber daya yang diperlukan tidak dapat dibuat dalam waktu yang cukup,'202 Diterima' seharusnya dikembalikan. |
| 202 | Server telah menerima permintaan, tetapi belum memrosesnya. Sama seperti halnya dapat ditolak, permintaan dapat atau tidak dieksekusi akhirnya. Dalam kasus operasi asinkron, tidak ada cara yang lebih mudah untuk melakukan ini daripada mengirim kode status ini. Tujuannya untuk mengembalikan 202 tanggapan kode status untuk memungkinkan server menerima permintaan dari proses lain (seperti batch-operasi dasar yang dilakukan hanya sekali sehari) tanpa perlu mempertahankan koneksi sisi klien ke server sampai operasi batch selesai. Dalam tanggapan menerima permintaan untuk pemrosesan dan mengembalikan 202 kode status, entitas yang kembalikan harus termasuk beberapa informasi yang menunjukkan keadaan proses saat ini, serta penunjuk ke monitor keadaan proses atau prediksi keadaan, sehingga pengguna dapat memperkirakan apakah operasi telah selesai. |
| 203 | Server sukses mengolah permintaan, tetapi informasi header entitas yang kembalikan bukan set deterministik yang valid di server asal, tetapi lokal atau ketiga-salinan pihak. Informasi saat ini mungkin subset atau superset dari versi asli. Contohnya, metadata yang mengandung sumber daya dapat membuat server asal mengetahui meta super. Menggunakan kode status ini tidak diperlukan, dan hanya sesuai jika respon kembalikan 200 OK tanpa kode status ini. |
| 204 | Server sukses mengolah permintaan, tetapi tidak perlu mengembalikan apapun konten fisik, dan ingin mengembalikan informasi meta yang diperbarui. Respon dapat berupa header entitas, mengembalikan informasi meta baru atau diperbarui. Jika informasi header ini ada, ia harus sejalan dengan variabel permintaan. Jika sisi klien adalah browser, maka browser pengguna harus mengejagikan halaman yang mengirim permintaan tanpa ada perubahan dalam tampilan dokumen, bahkan jika informasi meta baru atau diperbarui harus diterapkan kepada dokumen dalam tampilan aktif browser pengguna menurut spesifikasi. Sejak 204 respon yang larang untuk termasuk apapun isi pesan, ia selalu berakhir dengan baris kosong pertama setelah header. |
| 205 | Server sukses mengolah permintaan dan kembalikan tanpa ada. Tetapi berbeda dengan 204 Respon, respon yang kembalikan kode status ini memerlukan permintaan untuk mengatur ulang tampilan dokumen. Respon ini utamanya digunakan untuk mengatur ulang formulir segera setelah menerima input pengguna sehingga pengguna dapat dengan mudah memulai input lain. Seperti yang 204 respon, maka respon ini juga dilarang untuk mengandung pesan tubuh apapun dan berakhir dengan garis kosong pertama setelah header. |
| 206 | Server telah sukses memroses bagian dari permintaan GET. Alat unduh HTTP seperti FlashGet atau Xunlei menggunakan jenis respon ini untuk melaksanakan kontinyu titik putus atau untuk memecah dokumen besar menjadi beberapa segment unduh untuk diunduh secara bersamaan. Permintaan harus mengandung header Range untuk menunjukkan rentang konten yang diinginkan oleh sisi klien, dan dapat termasuk If-Range sebagai kondisi permintaan. Respon harus mengandung header fields berikut: Content-Range untuk menunjukkan rentang konten yang dihasilkan dalam respons ini; jika ini adalah multi-unduh segment dengan Content-Type multipart/byteranges, setiap bagian multi-part seharusnya mengandung sebuah Content-field Range untuk menunjukkan rentang konten bagian ini. Jika respons mengandung Content-Length, maka nilai nya harus sama dengan jumlah byte aktual dalam rentang konten yang dihasilkan. Tanggal ETag dan/atau Content-Location, jika permintaan yang sama seharusnya mengembalikan 2tanggapan 00. Expires, Cache-Kontrol, dan/atau Vary, jika nilai nya dapat berbeda dari nilai yang seharusnya dihasilkan oleh lainnya untuk variabel yang sama sebelumnya. Jika permintaan-validasi pengecer kuat Range, maka respon ini seharusnya tidak mengandung header entitas lain; jika permintaan respon ini menggunakan If-validasi pengecer lemah Range, maka respon ini seharusnya tidak mengandung header entitas lain; ini menghindari ketidaksempakatan antara konten entitas yang disimpan dan informasi header entitas yang diperbarui. Jika ini 2respon 00. Jika ETag atau Last-Modified yang sama, pengecer sisi klien seharusnya melarang gabungan konten yang dihasilkan dalam 206 respon dengan konten yang disimpan sebelumnya. Setiap pengecer yang tidak mendukung Range dan header-Header Range dilarang menyimpan konten yang dihasilkan oleh 206 respon. |
| 207 | Kode status yang diperpanjang oleh WebDAV (RFC 2518) yang mewakili bahwa badan pesan berikutnya akan berupa pesan XML, dan dapat mengandung urutan kode tanggapan yang bebas yang berdasarkan jumlah sub sebelumnya-. |
| 300 | Sumber permintaan memiliki berbagai opsi umpan, masing-masing dengan alamat yang khusus dan permintaan peramban-informasi. Pengguna atau peramban dapat memilih alamat yang disukai untuk alihlanjutan. Kecuali ini adalah permintaan HEAD, tanggapan seharusnya mengandung entitas yang berisi daftar atribut sumber daya dan alamat dari mana pengguna atau peramban dapat memilih alamat alihlanjutan yang paling sesuai. Format entitas ini ditentukan oleh format yang didefinisikan oleh Content-Tipe. Peramban dapat membuat pilihan yang paling sesuai secara otomatis berdasarkan format tanggapan dan kemampuan sendiri peramban. Tentu saja, negosiasi yang didorong oleh RFC 2616 tidak menentukan bagaimana pemilihan otomatis seperti ini harus dilakukan. Jika server sendiri sudah memiliki pemilihan umpan paling disukai, alamat umpan seharusnya disebutkan di Lokasi; peramban dapat menggunakan nilai Lokasi ini sebagai alamat untuk alihlanjutan otomatis. Selain itu, kecuali disebutkan lainnya, tanggapan ini juga dapat disimpan di cache. |
| 301 | Sumber permintaan telah dipindahkan ke lokasi baru secara permanen, dan referensi mendatang ke sumber ini seharusnya menggunakan salah satu URI yang diberikan oleh tanggapan ini. Jika memungkinkan, sisi klien dengan kemampuan edit tautan seharusnya secara otomatis mengubah alamat permintaan ke alamat yang diberikan dari server. Kecuali disebutkan lainnya, tanggapan ini juga dapat disimpan di cache. URI permanen baru seharusnya dikembalikan di bidang Lokasi tanggapan. Kecuali ini adalah permintaan HEAD, entitas tanggapan seharusnya mengandung tautan ke URI baru dan deskripsi singkat. Jika ini bukan permintaan GET atau HEAD, peramban dilarang dari otomatis mengalihkan kecuali konfirmasi oleh pengguna, karena kondisi permintaan dapat berubah akibatnya. Catatan: Untuk beberapa peramban yang menggunakan spesifikasi HTTP/1.0 protokol, saat mereka mengirim permintaan POST dan mendapatkan a 301 respon, permintaan dialihkan berikutnya akan berupa GET. |
| 302 | Sumber daya yang diminta sekarang menjawab permintaan sementara dari URI yang berbeda. Sejak alihkan seperti ini adalah sementara, sisi klien seharusnya terus mengirim permintaan mendatang ke alamat asli. Respon ini dapat disimpan di cache hanya jika disebutkan di Cache-Kontrol atau Expires. URI sementara baru harus dikembalikan di lapangan Lokasi dari respon. Kelebihan ini bukan permintaan HEAD, entitas respon seharusnya mengandung tautan ke URI baru dan deskripsi singkat. Jika ini bukan permintaan GET atau HEAD, browser melarang dialihkan otomatis kecuali disahkan oleh pengguna, karena kondisi permintaan dapat berubah sebagai akibatnya. Catatan: Meskipun RFC 1945 dan RFC 2068 spesifikasi tidak mengijinkan sisi klien untuk mengubah metode permintaan saat dialihkan, banyak browser yang ada menganggap 302 respon sebagai 303 respon dan gunakan GET untuk mengakses URI yang disebutkan di Lokasi, mengabaikan metode permintaan asli. Kode status 303 dan 307 ditambahkan untuk mengklarifikasi apa yang server mengharapkan dari sisi klien. |
| 303 | respon untuk permintaan saat ini dapat ditemukan di URI lain, dan sisi klien seharusnya mengakses sumber daya tersebut dengan GET. Metode ini ada utamanya untuk memungkinkan skrip-permintaan POST yang diaktifkan untuk dialihkan ke sumber daya baru. URI baru ini bukan referensi pengganti untuk sumber daya asli. Juga, 303 tanggapan dilarang disimpan. Tentu saja, permintaan kedua (pengalihan) dapat disimpan. URI baru seharusnya dikembalikan di lapangan Location tanggapan. Kelebihan, jika ini permintaan HEAD, entitas tanggapan seharusnya mengandung hyperlink ke URI baru dan deskripsi singkat. Catatan: Banyak browser sebelum HTTP/1.1 tidak mengerti 303 status dengan benar. Jika Anda perlu mempertimbangkan interaksi dengan browser ini, 302 kode status harus cukup, karena sebagian besar browser menangani 302 tanggapan dengan cara yang sama seperti yang diwajibkan di spesifikasi di atas untuk sisi klien untuk menangani 303 tanggapan. |
| 304 | Jika sisi klien mengirim permintaan GET bersyarat dan permintaan ini telah diijinkan, dan konten dokumen belum berubah (sejak kunjungan terakhir atau menurut kondisi permintaan), server seharusnya mengembalikan kode status ini. 304 tanggapan dilarang untuk mengandung badan pesan, jadi selalu berakhir dengan baris kosong pertama setelah header. Tanggapan harus mengandung informasi header berikut: Date, kecuali server ini tidak memiliki jam.
Jika server tanpa jam juga mengikuti aturan ini, maka server proksi dan sisi klien dapat menambahkan lapangan Date ke header tanggapan yang diterima sendiri (sesuai dengan RFC 2068), dan mekanisme pengecekan akan berjalan dengan baik. ETag dan/atau Content-Location, jika permintaan yang sama seharusnya mengembalikan 2tanggapan 00. Expires, Cache-Kontrol, dan/atau Vary, jika nilai nya dapat berbeda dari nilai yang sebelumnya untuk tanggapan lain untuk variabel yang sama.
Jika permintaan tanggapan ini menggunakan validasi pengecekan penyimpanan kuat, maka tanggapan ini tidak boleh mengandung header entitas lain; sebaliknya (contoh, permintaan GET bersyarat menggunakan validasi penyimpanan lemah), tanggapan ini dilarang untuk mengandung header entitas lain; ini menghindari ketidaksempakan antara konten entitas disimpan dan informasi header entitas yang diperbarui. Jika 304 tanggapan menunjukkan bahwa entitas saat ini tidak disimpan di cache, sistem caching harus mengabaikan tanggapan dan mengirim permintaan berulang-ulang tanpa batasan.
Jika sebuah 304 tanggapan diterima untuk memperbarui entri cache, sistem caching harus memperbarui seluruh entri untuk mencerminkan nilai semua lapangan yang diperbarui dalam tanggapan. |
| 305 | Sumber daya permintaan harus diakses melalui proksi yang ditentukan. Informasi URI proksi yang ditentukan diberikan di lapangan Lokasi. Penerima perlu mengirim permintaan terpisah berulang-ulang untuk mengakses sumber daya yang relevan melalui proksi ini. Hanya server asli yang dapat membangun 305 tanggapan. Catatan: Tidak ada eksplicit 305 tanggapan di RFC 2068 untuk mengalihkan permintaan tunggal, dan hanya dapat dibangun oleh server asli. Melupakan batasan ini dapat mengakibatkan konsekuensi keamanan yang serius. |
| 306 | Dalam versi terbaru spesifikasi, 306 kode status tidak lagi digunakan. |
| 307 | Sumber daya permintaan sekarang menjawab permintaan sementara dari URI yang berbeda. Sebab pengalihan seperti ini sementara, sisi klien harus terus mengirim permintaan mendatang ke alamat asli. Tanggapan ini hanya dapat disimpan di cache jika disebutkan di Cache-Kontrol atau Expires. URI sementara baru harus dikembalikan di lapangan Lokasi tanggapan. Kecuali ini adalah permintaan HEAD, entitas yang menjawab harus mengandung tautan yang mengarah ke URI baru dan deskripsi singkat. Sebab beberapa peramban tidak mengenali 307 untuk menambahkan informasi di atas supaya pengguna dapat memahami dan meminta akses ke URI baru.
Jika ini bukan permintaan GET atau HEAD, peramban melarang pengalihan otomatis kecuali disetujui pengguna, karena kondisi permintaan dapat berubah akibatnya. |
| 400 | 1. Semantiknya salah, dan permintaan saat ini tidak dapat dipahami oleh server. Kecewa, sisi klien seharusnya tidak mengirimkan permintaan secara berulang-ulang. 2. Parameter permintaan salah. |
| 401 | permintaan saat ini memerlukan otentikasi pengguna. Tanggapan harus mengandung WWW-header otentikasi untuk sumber daya yang diminta untuk meminta informasi pengguna. Sisi klien dapat mengirimkan permintaan kembali dengan informasi header otorisasi yang sesuai. Jika permintaan saat ini sudah mengandung sertifikat otorisasi, maka the 401 tanggapan menyatakan bahwa server telah menolak sertifikat-sertifikat tersebut. Jika the 401 tanggapan mengandung permintaan otentikasi yang sama seperti tanggapan sebelumnya, dan browser telah mencoba otentikasi setidaknya sekali, maka browser harus menampilkan informasi entitas yang terdapat dalam tanggapan, sebab informasi entitas ini dapat mengandung informasi diagnostik yang relevan. Lihat RFC 2617. |
| 402 | Kode status ini direservasi untuk kebutuhan masa mendatang. |
| 403 | Server memahami permintaan, tetapi menolak untuk melaksanakannya. Berbeda dengan a 401 tanggapan, otentikasi tidak membantu, dan permintaan tidak boleh diulang. Jika ini bukan permintaan HEAD, dan server ingin dapat menjelaskan alasannya permintaan tidak dapat dieksekusi, maka alasan penolakan harus dijelaskan dalam entitas. Tentu saja, server dapat juga mengembalikan sebuah 404 tanggapan jika ia tidak ingin klien mendapatkan informasi apapun. |
| 404 | Permintaan gagal, dan sumber daya yang diinginkan tidak ditemukan di server. Tidak ada informasi untuk memberitahu pengguna apakah kondisi ini sementara atau permanen. Jika server menyadari situasi, the 410 Kode status harus digunakan untuk memberitahu sumber daya lama bahwa ia tidak tersedia secara permanen karena mekanisme konfigurasi internal dan tidak ada alamat untuk melompat ke. The 404 Kode status digunakan secara luas ketika server tidak ingin mengungkapkan alasannya permintaan ditolak atau tidak ada tanggapan yang sesuai yang tersedia. |
| 405 | Metode permintaan yang dispecifikasikan di baris permintaan tidak dapat digunakan untuk meminta sumber daya yang seharusnya. Tanggapan harus mengembalikan kepala Allow yang menunjukkan daftar metode permintaan yang dapat diterima oleh sumber daya saat ini. Sejak metode PUT dan DELETE menulis ke sumber daya di server, sebagian besar server web tidak mendukung atau tidak mengizinkan metode permintaan di atas secara baku, dan akan mengembalikan 405 kesalahan untuk permintaan seperti itu. |
| 406 | Karakteristik konten sumber daya yang dipersilakan tidak memenuhi kondisi di kepala permintaan, sehingga entitas tanggapan tidak dapat dibuat. Kecewa, kecuali permintaan HEAD, tanggapan harus mengembalikan entitas yang memungkinkan pengguna atau browser untuk memilih karakteristik entitas yang paling sesuai dan daftar alamat. Format entitas ditentukan oleh jenis media yang ditentukan dalam Content-Kepala Type. Browser dapat membuat pilihan terbaik berdasarkan format dan kemampuan sendiri. Namun, spesifikasi tidak mendefinisikan kriteria untuk membuat pemilihan otomatis seperti itu. |
| 407 | Sama seperti 401 , kecuali bahwa sisi klien harus autentikasi di server proxy. Server proxy harus kembalikan Proxy-Autentikasi untuk autentikasi. Sisi klien dapat kembalikan tanggapan Proxy-Kepala Authorization untuk autentikasi. Lihat RFC 2617. |
| 408 | Permintaan habis waktu. Sisi klien tidak menyelesaikan pengiriman permintaan dalam waktu yang disediakan server untuk menunggu. Sisi klien dapat mengirimkan permintaan kembali kapan saja tanpa perubahan apapun. |
| 409 | Permintaan tidak dapat diselesaikan karena konflik dengan keadaan saat ini dari sumber daya yang dipersilakan. Kode ini hanya diizinkan digunakan jika dipercaya pengguna dapat memecahkan konflik dan akan mengirimkan permintaan baru. Tanggapan harus mengandung informasi yang cukup bagi pengguna untuk menemukan sumber konflik. Konflik biasanya terjadi dalam proses permintaan PUT. Contohnya, dalam versi-lingkungan yang dipertahankan, jika informasi versi yang disambungkan ke PUT-permintaan modifikasi yang disampaikan untuk sumber daya tertentu konflik dengan permintaan sebelumnya (ketiga)-permintaan pihak) server harus mengembalikan 409 kesalahan memberitahu pengguna bahwa permintaan tidak dapat diselesaikan.
Pada saat ini, entitas tanggapan mungkin mengandung perbandingan perbedaan antara dua versi yang konflik, sehingga pengguna dapat kirim kembali versi yang digabungkan. |
| 410 | Sumber daya yang diminta tidak lagi tersedia di server dan tidak memiliki alamat pengalihan yang diketahui. Kondisi ini seharusnya dianggap permanen. Jika memungkinkan, sisi klien dengan kemampuan edit tautan harus menghapus semua referensi ke alamat ini dengan izin pengguna. Jika server tidak tahu atau tidak dapat menentukan apakah kondisi ini permanen, maka 404 kode status harus digunakan. kecuali disebutkan lainnya, tanggapan ini dapat disimpan di cache. Tujuannya adalah 410 respon utamanya untuk membantu pemilik situs web memelihara situs web, memberitahu pengguna bahwa sumber daya tersebut tidak lagi tersedia, dan pemilik server menginginkan semua koneksi jarak jauh ke sumber daya ini dihapus.
Tipe peristiwa ini umum dalam waktu-nilai terbatas-layanan yang ditambahkan. Secara mirip, 410 respon digunakan untuk memberitahu sisi klien bahwa sumber daya yang asalnya milik individu tersebut tidak lagi tersedia di situs server saat ini. Tentu saja, sepenuhnya tergantung kepada pemilik server untuk menandai semua sumber daya yang tidak tersedia selama ini sebagai' 410 Gone ', dan berapa lama untuk mempertahankan tanda ini. |
| 411 | Server menolak untuk menerima permintaan tanpa menentukan Konten-Header panjang. Setelah menambahkan Konten yang sah-Header panjang menunjukkan panjang badan permintaan, sisi klien dapat mengirim permintaan kembali. |
| 412 | Server gagal memenuhi satu atau lebih dari syarat-syarat saat memverifikasi bahwa mereka diberikan dalam field header permintaan. Kode status ini memungkinkan sisi klien untuk menetapkan syarat di metadata yang diminta (data field header permintaan) saat mengambil sumber daya, sehingga mencegah metode permintaan dari diterapkan ke sumber daya selain yang diinginkan. |
| 413 | Server menolak untuk memproses permintaan saat ini karena permintaan mengirim lebih banyak data entitas daripada yang server siap atau dapat menangani. Dalam kasus ini, server dapat menutup koneksi untuk mencegah sisi klien terus mengirim permintaan. Jika situasi ini sementara, server seharusnya mengembalikan Retry-Setelah header respons untuk memberitahu sisi klien berapa lama yang dapat mencoba lagi. |
| 414 | URI yang diminta lebih panjang daripada yang dapat diartikan oleh server, sehingga server menolak untuk melayani permintaan. Ini jarang terjadi, dan kasus yang biasa termasuk: Form pengiriman yang seharusnya menggunakan metode POST menjadi metode GET, menyebabkan string query (Query String) terlalu panjang. Redirect URI "black holes", seperti setiap pengalihan menggunakan URI lama sebagai bagian dari URI baru, menyebabkan URI terlalu panjang setelah beberapa pengalihan. Klien mencoba menyerang server dengan bug keamanan yang ada di beberapa server.
Tipe server ini menggunakan-buffer panjang untuk membaca atau manipulasi URI yang diminta. Ketika parameter setelah GET melebihi nilai tertentu, kelebihan buffer dapat terjadi, menyebabkan eksekusi kode acak [1]. Server tanpa kerusakan seperti itu seharusnya mengembalikan 414 kode status. |
| 415 | Untuk metode permintaan saat ini dan sumber daya yang diminta, entitas yang disubmit dalam permintaan tidak berada dalam format yang didukung oleh server, sehingga permintaan ditolak. |
| 416 | Jika permintaan mengandung header Range, dan rentang data yang ditentukan dalam Range tidak sejalan dengan rentang yang tersedia sumber daya saat ini, dan If-Header range belum ditentukan dalam permintaan, server seharusnya mengembalikan 416 kode status. Jika Range menggunakan range byte, situasi ini berarti bahwa posisi byte pertama dari semua rentang data yang disebutkan dalam permintaan melebihi panjang sumber daya saat ini. Server seharusnya juga menyertakan Content-header entitas Range bersama dengan 416 kode status untuk menunjukkan panjang sumber daya saat ini. Tanggapan ini juga dilarang menggunakan multipart/byteranges sebagai kontennya-Tipe. |
| 417 | Konten yang diharapkan yang disebutkan di header permintaan Expect tidak dapat dipenuhi oleh server, atau server adalah server proxy yang memiliki bukti yang jelas bahwa konten yang diharapkan tidak dapat dipenuhi di node berikutnya dari jalur saat ini. |
| 421 | Jumlah koneksi ke server dari Alamat Protokol Internet tempat sisi klien saat ini berada melebihi maksimum yang diijinkan oleh server. Secara umum, Alamat Protokol Internet di sini merujuk kepada alamat sisi klien yang dilihat dari server (seperti alamat gateway atau server proxy pengguna). Dalam kasus ini, hitungan koneksi dapat melibatkan lebih dari satu pengguna akhir. |
| 422 | Jumlah koneksi ke server dari Alamat Protokol Internet tempat sisi klien saat ini berada melebihi maksimum yang diijinkan oleh server. Secara umum, Alamat Protokol Internet di sini merujuk kepada alamat sisi klien yang dilihat dari server (seperti alamat gateway atau server proxy pengguna). Dalam kasus ini, hitungan koneksi dapat melibatkan lebih dari satu pengguna akhir. |
| 422 | Permintaan yang disiapkan dengan benar, tetapi tidak dapat dijawab karena kesalahan semantik. (RFC 4918 WebDAV) 423 Dikunci Sumber daya saat ini terkunci. (RFC 4918 WebDAV) |
| 424 | Permintaan saat ini gagal karena kesalahan di permintaan sebelumnya, seperti PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Didefinisikan dalam rancangan WebDav Advanced Collections, tetapi tidak dalam Protokol WebDAV Sequential Set (RFC 3658). |
| 426 | Sisi klien seharusnya berpindah ke TLS/1.0. (RFC 2817) |
| 449 | Diperpanjang oleh Microsoft, permintaan harus diulang setelah melaksanakan tindakan yang sesuai. |
| 500 | Server menghadapi situasi yang tak terduga yang menghalangi penyelesaian permintaan. Secara umum, masalah ini terjadi ketika kode server gagal. |
| 501 | Server tidak mendukung fitur yang diperlukan oleh permintaan saat ini. Ketika server tidak dapat mengenali metode permintaan yang diminta dan tidak dapat mendukung permintaannya untuk sumber daya apapun. |
| 502 | Ketika server yang bekerja sebagai gateway atau proxy mencoba melaksanakan permintaan, ia menerima tanggapan yang tidak sah dari server yang ada di atas. |
| 503 | The server is currently unable to process requests due to temporary server maintenance or overload. This condition is temporary and will be restored after some time. If the delay time can be predicted, the response can include a Retry-After header to indicate the delay time. If this Retry-After information is not given, the client side should handle it as if it were a 500 response. Note: The existence of a 503 status code does not mean that the server must use it in the event of an overload. Some servers simply wish to deny the client's connection. |
| 504 | When a server working as a gateway or proxy attempts to execute a request, it fails to receive a response from an upstream server (identified by the URI, such as HTTP, FTP, LDAP) or a secondary server (such as DNS) in a timely manner. Note: Some proxy servers return a 400 or 500 error when the DNS query times out |
| 505 | The server does not support, or refuses to support, the version of HTTP used in the request. This implies that the server cannot or will not use the same version as the client side. The response should include an entity describing why the version is not supported and which protocols the server supports. |
| 506 | Extended by the Transparent Content Negotiation Protocol (RFC 2295), this represents an internal configuration error on the server: the requested negotiation variable resource is configured to use itself in a transparent content negotiation, and therefore is not an appropriate focus in a negotiation process. |
| 507 | The server cannot store the content necessary to complete the request. This condition is considered temporary. WebDAV (RFC 4918) |
| 509 | Server has reached bandwidth limit. This is not an official status code, but it is still widely used. |
| 510 | The policies required to acquire resources are not met. (RFC 2774) |
