| Kode status Http | Arti Kode Status |
|---|
| 100 | Klien harus terus mengirim permintaan. Respons sementara ini digunakan untuk memberi tahu klien bahwa sebagian dari permintaannya telah diterima oleh server dan tidak ditolak. Klien harus terus mengirimkan sisa permintaan, atau mengabaikan respons ini jika permintaan sudah selesai. Server harus mengirimkan respons akhir kepada klien ketika permintaan selesai. |
| 101 | Server telah memahami permintaan klien dan akan memberi tahu klien melalui header pesan Upgrade untuk menggunakan protokol yang berbeda untuk menyelesaikan permintaan. Setelah mengirimkan baris kosong terakhir dari respons ini, server akan beralih ke protokol yang ditentukan dalam header pesan Upgrade. Hal ini hanya boleh dilakukan jika memang lebih menguntungkan untuk beralih ke protokol baru. Misalnya, beralih ke versi baru HTTP lebih menguntungkan daripada versi yang lebih lama, atau beralih ke protokol waktu nyata dan sinkron untuk mengirimkan sumber daya yang memanfaatkan fitur-fitur tersebut. |
| 102 | Kode status, yang diperluas oleh WebDAV (RFC 2518), menunjukkan bahwa pemrosesan akan berlanjut. |
| 200 | Permintaan telah berhasil dan header respons atau badan data yang diinginkan oleh permintaan akan dikembalikan dengan respons ini. |
| 201 | Permintaan telah dipenuhi dan sumber daya baru telah dibuat seperti yang diminta oleh permintaan dan URI-nya telah dikembalikan dengan header Lokasi. Jika sumber daya yang diperlukan tidak dapat dibuat tepat waktu, '202 Diterima' harus dikembalikan. |
| 202 | Server telah menerima permintaan, tetapi belum memprosesnya. Sama seperti permintaan yang ditolak, pada akhirnya permintaan tersebut mungkin akan dieksekusi atau tidak. Dalam konteks operasi asinkron, tidak ada yang lebih nyaman daripada mengirimkan kode status ini. Tujuan mengembalikan respons dengan kode status 202 adalah untuk memungkinkan server menerima permintaan dari proses lain (seperti operasi berbasis batch yang dieksekusi hanya sekali sehari) tanpa harus membuat klien tetap terhubung ke server sampai operasi batch selesai sepenuhnya. Respons yang menerima permintaan untuk diproses dan mengembalikan kode status 202 HARUS menyertakan dalam entitas yang dikembalikan beberapa informasi yang menunjukkan status proses saat ini, serta penunjuk ke monitor status pemrosesan atau prediksi status sehingga pengguna dapat memperkirakan apakah operasi telah selesai. |
| 203 | Server telah berhasil memproses permintaan, tetapi meta-informasi tajuk entitas yang dikembalikan bukanlah kumpulan definitif yang valid di server asli, tetapi salinan dari pihak lokal atau ketiga. Informasi saat ini mungkin merupakan subset atau superset dari versi aslinya. Sebagai contoh, metadata yang berisi sumber daya dapat menyebabkan server asli mengetahui super informasi meta. Penggunaan kode status ini tidak diperlukan dan hanya sesuai jika respons akan mengembalikan 200 OK tanpa kode tersebut. |
| 204 | Server berhasil memproses permintaan, tetapi tidak perlu mengembalikan konten fisik apa pun dan ingin mengembalikan informasi meta yang telah diperbarui. Respons dapat mengembalikan informasi meta yang baru atau yang telah diperbarui dalam bentuk tajuk entitas. Jika header tersebut ada, header tersebut harus sesuai dengan variabel yang diminta. Jika klien adalah peramban, maka peramban pengguna HARUS mempertahankan halaman tempat permintaan dikirim tanpa perubahan tampilan dokumen, meskipun menurut spesifikasi, informasi meta yang baru atau yang diperbarui HARUS diterapkan ke dokumen dalam tampilan aktif peramban pengguna. Karena respons 204 dilarang berisi badan pesan apa pun, respons ini selalu diakhiri dengan baris kosong pertama setelah header pesan. |
| 205 | Server berhasil memproses permintaan dan tidak mengembalikan apa pun. Tidak seperti respons 204, respons yang mengembalikan kode status ini meminta pemohon untuk mengatur ulang tampilan dokumen. Respons ini terutama digunakan untuk mengatur ulang formulir segera setelah menerima input pengguna sehingga pengguna dapat dengan mudah memulai input lain. Seperti respons 204, respons ini dilarang berisi badan pesan apa pun dan diakhiri dengan baris kosong pertama setelah header pesan. |
| 206 | Server telah berhasil memproses bagian dari permintaan GET. Alat pengunduhan HTTP seperti FlashGet atau Thunderbolt menggunakan jenis respons ini untuk melakukan pengunduhan terputus-putus atau memecah dokumen besar menjadi beberapa segmen pengunduhan secara bersamaan. Permintaan harus berisi header Range untuk menunjukkan rentang konten yang ingin diterima klien, dan mungkin berisi If-Range sebagai kondisi permintaan. Respons harus berisi bidang header berikut: Content-Range untuk menunjukkan cakupan konten yang dikembalikan dalam respons ini; dalam kasus pengunduhan multi-segmen dengan Content-Type multipart/byterranges, setiap segmen multipart harus berisi bidang Content-Range yang menunjukkan cakupan konten dalam segmen tersebut. Jika respons berisi Panjang Konten, nilainya harus sesuai dengan jumlah byte yang sebenarnya dalam rentang konten yang dikembalikan. tanggal ETag dan/atau Lokasi-Konten, jika permintaan yang sama seharusnya mengembalikan respons 200. Kedaluwarsa, Kontrol-Cache, dan/atau Bervariasi, jika nilainya mungkin berbeda dari respons lain dengan variabel yang sama. Kedaluwarsa, Cache-Control, dan/atau Vary, jika nilainya mungkin berbeda dari nilai respons sebelumnya untuk variabel yang sama. Respons ini TIDAK BOLEH berisi header entitas lain jika permintaan menggunakan validasi cache kuat If-Range, dan TIDAK BOLEH berisi header entitas lain jika permintaan menggunakan validasi cache lemah If-Range; hal ini untuk menghindari ketidakkonsistenan antara konten entitas yang ditembolok dan informasi header entitas yang diperbarui. Jika tidak, respons ini HARUS berisi semua bidang tajuk entitas yang seharusnya dikembalikan dalam semua 200 respons yang seharusnya dikembalikan. Jika header ETag atau Last-Modified tidak sama persis, cache sisi klien HARUS melarang penggabungan konten yang dikembalikan dalam respons 206 dengan konten yang di-cache sebelumnya. Tembolok apa pun yang tidak mendukung header Range dan Content-Range dilarang menembolok konten yang dikembalikan oleh respons 206. |
| 207 | Kode status, seperti yang diperluas oleh WebDAV (RFC 2518), berarti bahwa badan pesan berikutnya akan berupa pesan XML dan mungkin berisi serangkaian kode respons terpisah, tergantung pada jumlah subpermintaan sebelumnya. |
| 300 | Sumber daya yang diminta memiliki serangkaian pesan balasan alternatif, masing-masing dengan alamat spesifik dan informasi negosiasi berbasis peramban. Pengguna atau peramban dapat memilih alamat yang diinginkan untuk pengalihan sendiri. Kecuali jika ini adalah permintaan HEAD, responsnya harus menyertakan entitas yang merupakan daftar karakteristik sumber daya dan alamat yang dapat digunakan pengguna atau peramban untuk memilih alamat pengalihan yang paling sesuai. Format entitas ini ditentukan oleh format definisi Tipe-Konten. Browser dapat secara otomatis membuat pilihan yang paling tepat berdasarkan format respons dan kemampuan browser itu sendiri. Tentu saja, spesifikasi RFC 2616 tidak menentukan bagaimana pilihan otomatis tersebut harus dibuat. Jika server itu sendiri sudah memiliki pilihan pengembalian yang lebih disukai, maka URI dari pengembalian ini harus ditentukan di Location; browser dapat menggunakan nilai Location ini sebagai alamat untuk pengalihan otomatis. Selain itu, respons ini juga dapat disimpan dalam cache kecuali ditentukan lain. |
| 301 | Sumber daya yang diminta telah dipindahkan secara permanen ke lokasi baru, dan semua rujukan di masa mendatang harus menggunakan salah satu dari beberapa URI yang dikembalikan dalam respons ini. Jika memungkinkan, klien dengan kemampuan pengeditan tautan harus secara otomatis mengubah alamat yang diminta ke alamat yang dikembalikan dari server. Respons ini juga dapat disimpan dalam cache kecuali ditentukan lain. URI permanen yang baru harus dikembalikan dalam bidang Lokasi pada respons. Kecuali jika ini adalah permintaan HEAD, entitas respons harus berisi hyperlink ke URI baru dan deskripsi singkat. Jika ini bukan permintaan GET atau HEAD, maka browser dilarang melakukan pengalihan secara otomatis kecuali jika dikonfirmasi oleh pengguna, karena ketentuan permintaan dapat berubah sebagai akibatnya. Catatan: Untuk beberapa browser yang menggunakan protokol HTTP/1.0, ketika mereka mengirim permintaan POST dan mendapatkan respons 301, permintaan pengalihan berikutnya adalah GET. |
| 302 | Sumber daya yang diminta sekarang untuk sementara waktu merespons permintaan dari URI yang berbeda. Karena pengalihan ini bersifat sementara, klien harus terus mengirim permintaan di masa mendatang ke alamat asli. Respons ini hanya dapat disimpan dalam cache jika ditentukan dalam Cache-Control atau Kedaluwarsa. URI sementara yang baru harus dikembalikan dalam bidang Lokasi pada respons. Kecuali jika ini adalah permintaan HEAD, entitas respons harus berisi hyperlink ke URI baru dan deskripsi singkat. Jika ini bukan permintaan GET atau HEAD, maka peramban dilarang melakukan pengalihan secara otomatis kecuali jika dikonfirmasi oleh pengguna, karena ketentuan permintaan dapat berubah sebagai akibatnya. Catatan: Meskipun spesifikasi RFC 1945 dan RFC 2068 tidak mengizinkan klien untuk mengubah metode permintaan pada pengalihan, banyak browser yang ada memperlakukan respons 302 sebagai respons 303 dan menggunakan GET untuk mengakses URI yang ditentukan dalam Lokasi, mengabaikan metode permintaan asli. Kode status 303 dan 307 telah ditambahkan untuk memperjelas respons apa yang diharapkan server dari klien. |
| 303 | Respons terhadap permintaan saat ini dapat ditemukan di URI lain dan klien harus mengakses sumber daya tersebut menggunakan GET. Metode ini ada terutama untuk memungkinkan keluaran permintaan POST yang diaktifkan skrip untuk dialihkan ke sumber daya yang baru. URI baru ini bukan merupakan referensi alternatif untuk sumber daya asli. Selain itu, respons 303 dilarang untuk di-cache. Tentu saja, permintaan kedua (pengalihan) dapat di-cache. URI baru harus dikembalikan dalam bidang Lokasi pada respons. Kecuali jika ini adalah permintaan HEAD, entitas respons harus berisi hyperlink ke URI baru dan deskripsi singkat. Catatan: Banyak browser sebelum versi HTTP/1.1 tidak memahami status 303 dengan baik. Jika interaksi dengan browser-browser ini perlu dipertimbangkan, kode status 302 seharusnya bisa digunakan, karena sebagian besar browser menangani respons 302 dengan cara yang sama persis dengan spesifikasi di atas yang mengharuskan klien menangani respons 303. |
| 304 | Server HARUS mengembalikan kode status ini jika klien mengirimkan permintaan GET bersyarat yang telah diizinkan dan konten dokumen (sejak kunjungan terakhir atau sesuai dengan kondisi permintaan) tidak berubah.304 Respons dilarang berisi badan pesan, dan oleh karena itu selalu diakhiri dengan baris kosong pertama setelah header pesan. Tanggapan HARUS berisi header berikut: Tanggal, kecuali jika server tidak memiliki jam. Jika server tanpa jam mengikuti aturan ini, maka server proxy dan klien dapat menambahkan bidang Tanggal ke header respons yang masuk sendiri (seperti yang ditentukan dalam RFC 2068), dan mekanisme caching akan bekerja dengan benar.ETag dan/atau Lokasi-Konten, jika permintaan yang sama akan mengembalikan respons 200.Kedaluwarsa Kedaluwarsa, Cache-Control, dan/atau Vary, jika nilainya mungkin berbeda dari nilai yang sesuai dengan respons sebelumnya untuk variabel yang sama. Jika permintaan respons ini menggunakan validasi cache yang kuat, maka respons ini tidak boleh berisi tajuk entitas lain; jika tidak (misalnya, permintaan GET bersyarat menggunakan validasi cache yang lemah), respons ini dilarang berisi tajuk entitas lain; hal ini untuk menghindari ketidakkonsistenan antara konten entitas yang di-cache dan informasi tajuk entitas yang diperbarui. Jika respons 304 mengindikasikan bahwa suatu entitas saat ini tidak ditembolok, sistem caching harus mengabaikan respons tersebut dan mengulangi permintaan tanpa batasan. Jika respons 304 diterima yang meminta agar entri cache diperbarui, sistem caching HARUS memperbarui seluruh entri untuk mencerminkan nilai semua bidang yang diperbarui dalam respons. |
| 305 | Bidang Lokasi akan memberikan informasi tentang URI di mana proxy yang ditentukan berada. penerima harus mengirim permintaan terpisah berulang kali untuk mengakses sumber daya melalui proxy ini. Hanya server asli yang dapat membuat respons 305. Catatan: Tidak jelas dari RFC 2068 bahwa respons 305 dimaksudkan untuk mengalihkan satu permintaan dan hanya dapat dibuat oleh server asli. Mengabaikan pembatasan ini dapat menyebabkan konsekuensi keamanan yang serius. |
| 306 | Pada versi terbaru dari spesifikasi, kode status 306 tidak lagi digunakan. |
| 307 | Sumber daya yang diminta sekarang untuk sementara menanggapi permintaan dari URI yang berbeda. Karena pengalihan tersebut bersifat sementara, klien harus terus mengirim permintaan di masa mendatang ke alamat asli. Respons ini hanya dapat disimpan dalam cache jika ditentukan dalam Cache-Control atau Kedaluwarsa. URI sementara yang baru harus dikembalikan dalam bidang Lokasi pada respons. Kecuali jika ini adalah permintaan HEAD, entitas respons harus berisi hyperlink ke URI baru dan deskripsi singkat. Karena beberapa browser tidak mengenali respons 307, informasi di atas perlu ditambahkan agar pengguna dapat memahami dan meminta akses ke URI yang baru. Jika ini bukan permintaan GET atau HEAD, maka browser melarang pengalihan otomatis, kecuali jika dikonfirmasi oleh pengguna, karena kondisi permintaan dapat berubah. |
| 400 | 1. Terdapat kesalahan semantik dan permintaan saat ini tidak dapat dipahami oleh server. Kecuali jika dimodifikasi, klien tidak boleh berulang kali mengirimkan permintaan ini. 2. Parameter permintaan salah. |
| 401 | Permintaan saat ini membutuhkan otentikasi pengguna. Tanggapan harus berisi header WWW-Autentikasi untuk sumber daya yang diminta untuk meminta informasi pengguna. Klien dapat berulang kali mengirimkan permintaan yang berisi informasi header Otorisasi yang sesuai. Jika permintaan saat ini sudah berisi kredensial Otorisasi, maka respons 401 berarti server memverifikasi bahwa kredensial tersebut telah ditolak. Jika respons 401 berisi kueri autentikasi yang sama dengan respons sebelumnya, dan peramban telah mencoba autentikasi setidaknya satu kali, maka peramban HARUS menampilkan informasi entitas yang terkandung di dalam respons kepada pengguna, karena informasi entitas ini mungkin berisi informasi diagnostik yang relevan. Lihat RFC 2617. |
| 402 | Kode status ini dicadangkan untuk kemungkinan kebutuhan di masa mendatang. |
| 403 | Server telah memahami permintaan tetapi menolak untuk menjalankannya. Tidak seperti respons 401, autentikasi tidak memberikan bantuan apa pun, dan permintaan ini tidak boleh dikirim ulang. Jika ini bukan permintaan HEAD dan server ingin menyampaikan dengan jelas mengapa permintaan tidak dapat dieksekusi, maka alasan penolakan harus dijelaskan di dalam entitas. Tentu saja server juga dapat mengembalikan respons 404 jika tidak ingin memberikan informasi apa pun kepada klien. |
| 404 | Permintaan gagal, sumber daya yang diminta tidak ditemukan di server. Tidak ada informasi untuk memberi tahu pengguna apakah situasi ini bersifat sementara atau permanen. Jika server mengetahui situasi tersebut, server harus menggunakan kode status 410 untuk memberi tahu pengguna bahwa sumber daya lama tidak tersedia secara permanen karena beberapa mekanisme konfigurasi internal dan tidak ada pengalihan yang tersedia. 404 banyak digunakan ketika server tidak ingin mengungkapkan mengapa permintaan ditolak atau ketika tidak ada respons lain yang sesuai yang tersedia. |
| 405 | Metode permintaan yang ditentukan dalam baris permintaan tidak dapat digunakan untuk meminta sumber daya yang sesuai. Respons harus mengembalikan header Izinkan yang menunjukkan daftar metode permintaan yang dapat diterima untuk sumber daya saat ini. Karena metode PUT dan DELETE menulis ke sumber daya di server, sebagian besar server web tidak mendukung metode permintaan ini atau tidak mengizinkannya secara default, dan akan mengembalikan kesalahan 405 untuk permintaan tersebut. |
| 406 | Karakteristik konten sumber daya yang diminta tidak memenuhi ketentuan dalam header permintaan, dan entitas respons tidak dapat dihasilkan. Kecuali jika ini adalah permintaan HEAD, respons harus mengembalikan entitas yang berisi daftar properti entitas dan alamat yang dapat dipilih oleh pengguna atau peramban yang paling sesuai. Format entitas ditentukan oleh jenis media yang ditentukan dalam header Tipe-Konten. Browser dapat membuat pilihan terbaik mereka sendiri berdasarkan format dan kemampuan mereka sendiri. Namun, spesifikasi tidak mendefinisikan kriteria apa pun untuk membuat pilihan otomatis tersebut. |
| 407 | Mirip dengan respons 401, kecuali bahwa klien HARUS mengautentikasi di server proxy. Server proxy HARUS mengembalikan Proxy-Autentikasi untuk interogasi identitas. Klien MUNGKIN mengembalikan header Otorisasi-Proksi untuk autentikasi. Lihat RFC 2617. |
| 408 | Batas waktu permintaan. Klien tidak menyelesaikan pengiriman permintaan dalam waktu yang disediakan server untuk menunggu. Klien dapat mengirim ulang permintaan kapan saja tanpa membuat perubahan apa pun. |
| 409 | Permintaan tidak dapat diselesaikan karena adanya konflik dengan kondisi sumber daya yang diminta saat ini. Kode ini hanya diizinkan untuk digunakan jika pengguna dianggap dapat menyelesaikan konflik dan mengirimkan kembali permintaan baru. Respons yang diberikan harus berisi informasi yang cukup bagi pengguna untuk menemukan sumber konflik. Konflik biasanya terjadi dalam pemrosesan permintaan PUT. Misalnya, dalam lingkungan pemeriksaan versi, jika informasi versi yang dilampirkan pada PUT yang dikirimkan untuk memodifikasi sumber daya tertentu bertentangan dengan permintaan (pihak ketiga) sebelumnya, server akan mengembalikan kesalahan 409 yang memberi tahu pengguna bahwa permintaan tidak dapat diselesaikan. Dalam kasus ini, entitas respons kemungkinan besar berisi perbandingan perbedaan antara dua versi yang bertentangan sehingga pengguna dapat mengirimkan ulang versi baru setelah penggabungan. |
| 410 | Sumber daya yang diminta tidak lagi tersedia di server dan tidak memiliki alamat penerusan yang diketahui. Kondisi seperti ini harus dianggap permanen. Jika memungkinkan, klien dengan kemampuan pengeditan tautan harus menghapus semua referensi ke alamat ini dengan izin pengguna. Jika server tidak mengetahui atau tidak dapat menentukan apakah kondisi ini permanen, maka kode status 404 harus digunakan. Kecuali dinyatakan lain, respons ini dapat di-cache.410 Tujuan dari respons ini terutama untuk membantu webmaster dalam memelihara situs dengan menginformasikan kepada pengguna bahwa sumber daya tersebut tidak lagi tersedia dan bahwa pemilik server ingin semua koneksi jarak jauh ke sumber daya ini juga dihapus. Jenis peristiwa ini umum terjadi pada layanan bernilai tambah yang terbatas waktu. Demikian pula, respons 410 digunakan untuk memberi tahu klien bahwa sumber daya yang awalnya milik individu di situs server saat ini tidak lagi tersedia. Tentu saja, sepenuhnya tergantung pada pemilik server apakah semua sumber daya yang tidak tersedia secara permanen perlu ditandai sebagai '410 Hilang' dan berapa lama penandaan ini perlu dipertahankan. |
| 411 | Server menolak untuk menerima permintaan tanpa header Content-Length yang ditentukan. Setelah menambahkan header Content-Length yang valid yang menunjukkan panjang badan pesan permintaan, klien dapat mengirimkan permintaan lagi. |
| 412 | Server gagal memenuhi satu atau beberapa prasyarat ketika memverifikasi bahwa prasyarat tersebut diberikan dalam bidang header permintaan. Kode status ini memungkinkan klien untuk menetapkan prasyarat dalam meta-pesan permintaan (data bidang header permintaan) ketika mendapatkan sumber daya, sehingga mencegah metode permintaan diterapkan pada sumber daya selain konten yang diinginkannya. |
| 413 | Server menolak untuk memproses permintaan saat ini karena mengirimkan data entitas dengan ukuran yang lebih besar daripada yang dapat ditangani oleh server. Dalam kasus ini, server dapat menutup koneksi untuk mencegah klien melanjutkan pengiriman permintaan ini. Jika kondisi ini bersifat sementara, server harus mengembalikan header respons Coba Lagi untuk memberi tahu klien berapa lama waktu yang dibutuhkan untuk mencoba kembali. |
| 414 | Panjang URI permintaan melebihi panjang yang dapat ditafsirkan oleh server, sehingga server menolak untuk melayani permintaan tersebut. Hal ini jarang terjadi, dan sering kali terjadi ketika pengiriman formulir yang seharusnya menggunakan metode POST menjadi metode GET, sehingga menghasilkan Query String yang panjang. Mengalihkan "lubang hitam" URI, seperti menggunakan URI lama sebagai bagian dari URI baru pada setiap pengalihan, sehingga menghasilkan URI yang panjang setelah beberapa kali pengalihan. Klien mencoba menyerang server dengan mengeksploitasi kerentanan keamanan yang ada di beberapa server. Server tersebut menggunakan buffer dengan panjang tetap untuk membaca atau memanipulasi URI dari sebuah permintaan, dan ketika parameter setelah GET melebihi nilai tertentu, buffer overflow dapat terjadi, yang menyebabkan eksekusi kode yang sewenang-wenang [1]. Server tanpa kerentanan seperti itu seharusnya mengembalikan kode status 414. |
| 415 | Untuk metode yang saat ini diminta dan sumber daya yang diminta, entitas yang dikirimkan dalam permintaan tidak dalam format yang didukung di server, sehingga permintaan ditolak. |
| 416 | Jika permintaan berisi header permintaan Range, dan rentang data apa pun yang ditentukan dalam Range tidak tumpang tindih dengan rentang yang tersedia untuk sumber daya saat ini, dan header permintaan If-Range tidak ditentukan dalam permintaan, maka server harus mengembalikan kode status 416. Jika Range menggunakan rentang byte, maka ini terjadi jika posisi byte pertama dari semua rentang data yang ditentukan dalam permintaan melebihi panjang sumber daya saat ini. Server juga harus menyertakan header entitas Content-Range yang menentukan panjang sumber daya saat ini bersama dengan kode status 416. Respons ini juga dilarang menggunakan multipart/byteranges sebagai Tipe-Content. |
| 417 | Konten yang diharapkan yang ditentukan dalam header permintaan Expect tidak dapat dipenuhi oleh server, atau server ini adalah server proxy yang memiliki bukti yang jelas bahwa konten Expect tidak dapat dipenuhi di node berikutnya dalam rute saat ini. |
| 421 | Jumlah koneksi ke server dari alamat IP tempat klien saat ini berada melebihi batas maksimum yang diizinkan oleh server. Biasanya, alamat IP di sini mengacu pada alamat klien seperti yang terlihat dari server (misalnya, gateway pengguna atau alamat server proxy). Dalam kasus ini, jumlah koneksi mungkin melibatkan lebih dari satu pengguna akhir. |
| 422 | Jumlah koneksi ke server dari alamat IP klien saat ini melebihi batas maksimum yang diizinkan oleh server. Biasanya, alamat IP di sini mengacu pada alamat klien seperti yang terlihat dari server (misalnya, gateway pengguna atau alamat server proxy). Dalam kasus ini, jumlah koneksi mungkin melibatkan lebih dari satu pengguna akhir. |
| 422 | Permintaan diformat dengan benar, tetapi tidak dapat ditanggapi karena mengandung kesalahan semantik. (RFC 4918 WebDAV) 423 Terkunci Sumber daya saat ini terkunci. (RFC 4918 WebDAV) |
| 424 | Permintaan saat ini gagal karena kesalahan yang terjadi pada permintaan sebelumnya, seperti PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Didefinisikan dalam draf Koleksi Lanjutan WebDav, tetapi tidak muncul dalam Protokol Koleksi Berurutan WebDAV (RFC 3658). |
| 426 | Klien harus beralih ke TLS/1.0. (RFC 2817) |
| 449 | Diperluas oleh Microsoft untuk menyatakan bahwa permintaan harus dicoba kembali setelah tindakan yang sesuai dilakukan. |
| 500 | Server mengalami kondisi tak terduga yang mencegahnya menyelesaikan pemrosesan permintaan. Biasanya, masalah ini terjadi ketika ada kesalahan dalam kode program server. |
| 501 | Server tidak mendukung fitur tertentu yang diperlukan untuk permintaan saat ini. Ketika server tidak dapat mengenali metode yang diminta dan tidak dapat mendukung permintaan sumber daya apa pun. |
| 502 | Server yang bekerja sebagai gateway atau proxy menerima respons yang tidak valid dari server hulu saat mencoba menjalankan permintaan. |
| 503 | Server saat ini tidak dapat memproses permintaan karena pemeliharaan server sementara atau kelebihan beban. Kondisi ini bersifat sementara dan akan pulih setelah beberapa waktu. Jika penundaan dapat diperkirakan, respons dapat menyertakan header Coba Lagi untuk menunjukkan penundaan. Jika informasi Retry-After ini tidak diberikan, maka klien harus menanganinya dengan cara yang sama seperti respons 500. Catatan: Keberadaan kode status 503 tidak berarti bahwa server harus menggunakannya jika kelebihan beban. Beberapa server hanya ingin menolak koneksi klien. |
| 504 | Server yang bekerja sebagai gateway atau proxy yang mencoba melakukan permintaan gagal menerima respons tepat waktu dari server hulu (server yang diidentifikasi dengan URI, seperti HTTP, FTP, LDAP) atau server sekunder (seperti DNS). Catatan: Beberapa server proxy mengembalikan kesalahan 400 atau 500 ketika pencarian DNS habis. |
| 505 | Server tidak mendukung, atau menolak mendukung, versi HTTP yang digunakan dalam permintaan. Ini menyiratkan bahwa server tidak dapat atau tidak mau menggunakan versi yang sama dengan klien. Respons harus berisi entitas yang menjelaskan mengapa versi tersebut tidak didukung dan protokol mana yang didukung oleh server. |
| 506 | Diperluas oleh Protokol Negosiasi Konten Transparan (RFC 2295) untuk merepresentasikan kesalahan konfigurasi internal di pihak server: sumber daya Varian Negosiasi yang diminta dikonfigurasikan untuk menggunakan dirinya sendiri dalam negosiasi konten transparan, dan oleh karena itu bukan merupakan fokus yang tepat dalam proses negosiasi. |
| 507 | Server tidak dapat menyimpan konten yang diperlukan untuk menyelesaikan permintaan. Kondisi ini dianggap bersifat sementara.WebDAV (RFC 4918) |
| 509 | Server mencapai batas bandwidth-nya. Ini bukan kode status resmi, tetapi masih digunakan secara luas. |
| 510 | Kebijakan yang diperlukan untuk mendapatkan sumber daya tidak terpenuhi. (RFC 2774) |