| Kode Status HTTP | Arti kod status |
|---|
| 100 | Pihak kiri seharusnya terus menghantar permintaan. Tanggapan sementara ini digunakan untuk memberitahu pihak kiri bahawa beberapa permintaannya telah diterima oleh pelayan dan belum ditolak. Pihak kiri seharusnya terus menghantar permintaan yang tersisa, atau abaikan tanggapan jika permintaan telah selesai. Pelayan mesti menghantar tanggapan akhir kepada pihak kiri setelah permintaan selesai. |
| 101 | Server memahami permintaan klien dan akan memberitahu sisi klien melalui header Upgrade untuk menggunakan protokol yang lain untuk menyelesaikan permintaan. Setelah mengirim baris kosong terakhir dalam tanggapan, server akan berpindah ke protokol yang ditentukan dalam header Upgrade. Tindakan sejenis hanya harus diambil saat pergantian ke protokol yang baru lebih bermanfaat. Contohnya, pergantian ke versi HTTP yang baru memiliki kelebihan atas versi yang lama, atau pergantian ke yang sebenarnya-waktu dan protokol sinkron untuk pengiriman sumber daya yang menikmati fitur ini. |
| 102 | Kode status yang diperpanjang oleh WebDAV (RFC 2518) menunjukkan bahwa proses akan terus berlanjut. |
| 200. | Permintaan sukses, dan header tanggapan yang diinginkan atau badan data dikembalikan bersama tanggapan. |
| 201 | Permintaan telah terpenuhi, dan sumber daya baru telah dibuat berdasarkan permintaan, dan URI-nya dikembalikan 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 memprosesnya. Seperti yang mungkin ditolak, permintaan mungkin atau mungkin tidak dieksekusi akhirnya. Dalam kasus operasi asinkron, cara yang paling mudah untuk melakukan ini adalah mengirim kode status ini. Tujuannya adalah untuk mengembalikan 202 balasan kode status untuk memungkinkan server menerima permintaan dari proses lain (seperti batch-operasi dasar yang dijalankan hanya sekali sehari) tanpa perlu mempertahankan koneksi sisi klien ke server sampai operasi batch selesai. Dalam tanggapan menerima permintaan untuk pengolahan dan mengembalikan 202 kod status, entiti yang diembalikkan seharusnya mengandungi beberapa maklumat yang menunjukkan keadaan proses semasa, serta penunjuk kepada pemantau keadaan proses atau ramalan keadaan, supaya pengguna dapat mengestimasi sama ada operasi telah selesai atau belum. |
| 203 | Penggunaan pelayan berjaya menangani permintaan, tetapi maklumat pengepala entiti meta yang diembalikkan bukan set deterministik yang sah di pelayan asal, tetapi set tempatan atau ketiga-salinan. Maklumat semasa mungkin adalah subset atau superset daripada versi asal. Contohnya, metadata mengandungi sumber boleh mendorong pelayan asal mengetahui meta super. Penggunaan kod status ini bukan perlu, dan hanya sesuai jika pernyataan mengembalikan 200 OK tanpa kod status ini. |
| 204 | Penggunaan pelayan berjaya menangani permintaan, tetapi tiada kandungan fizikal perlu diembalikkan, dan mahu mengembalikan maklumat meta yang diperbaharui. Pernyataan boleh berbentuk pengepala entiti, mengembalikan maklumat meta baru atau diperbaharui. Jika maklumat pengepala ini wujud, ia seharusnya sepadan dengan pemintaan variabel. Jika bahagian klien adalah pelayar, pelayar pengguna seharusnya mengekalkan halaman yang menghantar permintaan tanpa sebarang perubahan kepada paparan dokumen, walaupun maklumat meta baru atau diperbaharui seharusnya diterapkan kepada dokumen dalam paparan aktif pelayar pengguna menurut spesifikasi. Sejak 204 Penghantaran yang dilarang mengandungi sebarang badan mesej, ia selalu berakhir dengan baris kosong pertama selepas pengepala. |
| 205 | Penggunaan pelayan berjaya menangani permintaan dan mengembalikan tiada. Tetapi berbeza dengan 204 Penghantaran, penghantaran yang mengembalikan kod status ini memerlukan peminta untuk mengesahkan semula paparan dokumen. Pernyataan ini utamanya digunakan untuk mengesahkan semula bentuk segera selepas menerima input pengguna supaya pengguna dapat mulai input lain dengan mudah. Seperti dengan 204 tindakan balasan, tindakan balasan ini juga dihalangi daripada mengandungi sebarang badan mesej dan berakhir dengan baris kosong pertama selepas header. |
| 206 | Pelayan telah berjaya memproses sebahagian daripada permintaan GET. Alat muat turun HTTP seperti FlashGet atau Xunlei menggunakan jenis tindakan balasan ini untuk melaksanakan lanjutan titik puncak atau untuk memecahkan dokumen besar menjadi beberapa segmen muat turun untuk muat turun secara bersamaan. Permintaan mesti mengandungi header Range untuk menunjukkan kawasan konten yang dikehendaki oleh pihak klien, dan boleh mengandungi If-Range sebagai kondisi permintaan. Tindakan balasan mesti mengandungi lapangan header berikut: Content-Range untuk menunjukkan kawasan konten yang dihasilkan dalam tindakan balasan; jika ia adalah multi-Muat turun segment dengan Content-Jenis berbagai jenis/byteranges, setiap segmen berbagai jenis seharusnya mengandungi sebarang-Lapangan Range untuk menunjukkan kawasan konten segment ini. Jika tindakan balasan mengandungi Content-Panjang, maka nilai ini mesti sepadan dengan bilangan byte sebenar dalam kawasan konten yang dihasilkan. Tarikh ETag dan/atau Kandungan-Lokasi, jika permintaan yang sama seharusnya mengembalikan tanggapan yang sama 200 tanggapan. Masa berlaku, Cadangan-Kawalan, dan/atau Vary, jika nilai ini mungkin berbeza daripada nilai yang sepadan dengan tindakan balasan lain untuk yang sama variabel sebelum ini. Jika tindakan balasan ini menggunakan If-Pemvalidasian cache kuat Range, maka tindakan balasan ini seharusnya tidak mengandungi sebarang header entiti lain; jika tindakan balasan ini menggunakan If-Pemvalidasian cache lemah Range, maka tindakan balasan ini seharusnya tidak mengandungi sebarang header entiti lain; ini mengelakkan ketidak konsistenan antara konten entiti yang disimpan dan informasi header entiti yang diperbaharui. Jika bukan, tindakan balasan ini seharusnya mengandungi semua lapangan header entiti yang seharusnya diembalikan dalam 200 tindakan balasan. Jika ETag atau Last-Modified header yang tidak sepadan, penukaran sisi klien seharusnya menghalangi penggabungan konten yang dihasilkan dalam 206 tindakan balasan dengan sebarang konten yang disimpan sebelum ini. Setiap penukaran yang tidak mendukung Range dan pemainan-Pemainan Range dihalangi daripada menyimpan konten yang dihasilkan oleh 206 tindakan balasan. |
| 207 | Kod status yang diperpanjang oleh WebDAV (RFC 2518) menunjukkan bahwa badan pesan berikutnya akan berupa pesan XML, dan dapat mengandung serangkaian kode tanggapan yang bebas yang tergantung pada jumlah sub sebelumnya-. |
| 300 | Sumber yang diminta memiliki berbagai opsi umpan balik, masing-masing dengan alamat khususnya dan permintaan peramban-informasi. Pengguna atau peramban dapat memilih alamat yang disukai untuk alihkan. Kecuali ini adalah permintaan HEAD, tanggapan seharusnya termasuk entitas yang berisi daftar atribut sumber dan alamat yang pengguna atau peramban dapat memilih alamat alihkan yang paling sesuai. Format entitas ini ditentukan oleh format yang didefinisikan oleh Content-Jenis. Peramban dapat membuat pilihan yang paling sesuai berdasarkan format tanggapan dan kemampuan sendiri. Tentu saja, negosiasi yang dipicu oleh RFC 2616 tidak menentukan bagaimana pemilihan otomatis seperti ini harus dilakukan. Jika server sendiri sudah memiliki pemilihan umpan balik yang disukai, alamat umpan balik seharusnya disebutkan di Lokasi; peramban dapat menggunakan nilai Lokasi ini sebagai alamat untuk alihkan otomatis. Selain itu, kecuali disebutkan lainnya, tanggapan ini juga dapat disimpan di cache. |
| 301 | Sumber yang diminta telah dipindahkan ke lokasi baru secara kekal, dan referensi mendatang kepada 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 yang diminta ke alamat yang diberikan dari server. Kecuali disebutkan lainnya, tanggapan ini juga dapat disimpan di cache. URI kekal baru seharusnya dikembalikan di lapangan 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 secara otomatis mengalihkan kecuali disahkan 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 pembalasan, permintaan alihkan berikutnya akan menjadi GET. |
| 302 | Sumber daya yang diminta sekarang menjawab permintaan sementara dari URI yang berbeda. Sejak alihkan seperti ini 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 pembalasan. kecuali ini adalah permintaan HEAD, entitas pembalasan harus mengandung hyperlink ke URI baru dan deskripsi singkat. Jika ini bukan permintaan GET atau HEAD, peramban melarang alihkan otomatis kecuali disahkan pengguna, karena kondisi permintaan dapat berubah akibatnya. Catatan: Meskipun RFC 1945 dan RFC 2068 spesifikasi tidak mengijinkan sisi klien untuk mengubah metode permintaan saat dialihkan, banyak peramban yang ada menganggap 302 pembalasan sebagai 303 pembalasan dan gunakan GET untuk mengakses URI yang disebutkan di Lokasi, mengabaikan metode permintaan asli. Kode status 303 dan 307 ditambahkan untuk mengklarifikasi apa yang diharapkan server dari sisi klien. |
| 303 | pembalasan permintaan saat ini dapat ditemukan di URI lain, dan sisi klien seharusnya mendapatkan akses GET ke sumber daya itu. Metode ini ada utamanya untuk memungkinkan skrip-pemindahan output permintaan POST diaktifkan untuk dialihkan ke sumber daya baru. URI baru ini bukan referensi pengganti kepada sumber daya asli. Juga, 303 tanggapan dilarang disimpan di cadangan. Tentu saja, permintaan kedua (pengalihan) dapat disimpan di cadangan. URI baru seharusnya dikembalikan di medan Lokasi tanggapan. Kecuali ini adalah permintaan HEAD, entiti tanggapan harus mengandungi tautan ke URI baru dan deskripsi singkat. Catatan: Banyak pelayar sebelum HTTP/1.1 tidak memahami 303 status dengan benar. Jika Anda perlu mempertimbangkan interaksi dengan pelayar ini, yang 302 kode status seharusnya cukup, karena sebagian besar pelayar mengelola 302 tanggapan dengan cara yang sama seperti yang diharapkan klien untuk menangani di spesifikasi di atas 303 tanggapan. |
| 304 | Jika sisi klien mengirim permintaan GET bersyarat dan permintaan telah diijinkan, dan kandungan dokumen belum berubah (sejak kunjungan terakhir atau menurut kondisi permintaan), pelayan seharusnya mengembalikan kode status ini. 304 tanggapan dilarang mengandungi badan pesan, jadi selalu berakhir dengan baris kosong pertama setelah header. Tanggapan harus mengandungi informasi header berikut: Tarikh, kecuali pelayan ini tidak memiliki jam.
Jika pelayan tanpa jam juga mengikuti aturan ini, maka pelayan proksi dan sisi klien dapat menambahkan medan Tarikh ke tanggapan header yang diterima sendiri (sebagaimana dijelaskan dalam RFC 2068), dan mekanisme pengecapan akan berfungsi dengan baik. ETag dan/atau Kandungan-Lokasi, jika permintaan yang sama seharusnya mengembalikan tanggapan yang sama 200 tanggapan. Masa berlaku, Cadangan-Kawalan, dan/atau Vary, jika nilai yang mungkin berbeda dari nilai yang sebelumnya untuk tanggapan lain untuk variabel yang sama.
Jika permintaan tanggapan ini menggunakan pengesahan cadangan kuat, maka tanggapan ini tidak boleh mengandungi penghormatan entiti lain; jika tidak (contohnya, permintaan GET bersyarat menggunakan pengesahan cadangan lemah), tanggapan ini dilarang mengandungi penghormatan entiti lain; ini menghindari ketidakseimbangan antara kandungan entiti cadangan dan informasi penghormatan entiti yang diperbarui. Jika 304 balasan menunjukkan bahawa entiti bukan lagi disimpan di cache, sistem cache mesti mengabaikan balasan dan menghantar permintaan berulang tanpa larangan.
Jika seorang 304 balasan diterima untuk mengemaskini kemasukan cache, sistem cache mesti mengemaskini kemasukan sepenuhnya untuk menunjukkan nilai semua medan yang dikemaskini dalam balasan. |
| 305 | Sumber yang dipinta mesti diakses melalui proksi yang dinyatakan. Maklumat URI proksi yang dinyatakan diberikan di medan Lokasi. Penerima perlu menghantar permintaan yang berasingan untuk mengakses sumber yang berkaitan melalui proksi ini. Hanya pelayan asal yang boleh 305 balasan. Nota: Tidak ada pengesahan eksplisit 305 balasan dalam RFC 2068 untuk mendorong permintaan tunggal, dan hanya dapat diwujudkan oleh pelayan asal. Melanggar larangan ini boleh membawa keakibat keselamatan yang serius. |
| 306 | Dalam versi terkini spesifikasi, 306 kod status yang tidak lagi digunakan. |
| 307 | Sumber yang dipinta kini menjawab permintaan sementara daripada URI yang berbeza. Sejak pindahan seperti ini adalah sementara, bahagian klien harus terus menghantar permintaan mendatang ke alamat asal. Balasan ini hanya boleh disimpan di cache jika dinyatakan di Cache-Kawalan atau Expires. URI sementara baru perlu diembalikan di medan Lokasi balasan. Kecuali ini adalah permintaan HEAD, entiti yang bertindak harus mengandungi hiperlink yang mengarah ke URI baru dan deskripsi singkat. Sejak beberapa pelayar tidak mengenal 307 balasan, maklumat di atas perlu ditambahkan supaya pengguna dapat memahami dan meminta akses ke URI baru.
Jika ini bukan permintaan GET atau HEAD, pelayar akan melarang pindahan otomatis kecuali disahkan pengguna, kerana kondisi permintaan boleh berubah akibat itu. |
| 400 | 1. Semantiknya salah, dan permintaan saat ini tidak dapat dipahami oleh server. kecuali diubah, sisi kiri seharusnya tidak mengulangi mengajukan permintaan. 2. Parameter permintaan salah. |
| 401 | permintaan saat ini memerlukan pengesahan pengguna. Balasan harus mengandung tajuk WWW-tajuk pengesahan untuk sumber permintaan untuk meminta informasi pengguna. Sisi kiri dapat mengulangi permintaan dengan tajuk pengesahan informasi Authorization yang sesuai. Jika permintaan saat ini sudah mengandung sertifikat Authorization, maka 401 balasan menyatakan bahwa server telah menolak sertifikat yang bersangkutan. Jika 401 balasan mengandung permintaan pengesahan yang sama seperti balasan sebelumnya, dan browser telah mencoba pengesahan setidaknya sekali, maka browser harus menampilkan informasi entitas yang terdapat dalam balasan, 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 401 balasan, pengesahan 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 404 balasan jika ia tidak mau pelanggan mendapatkan sebarang informasi. |
| 404 | Permintaan gagal, dan sumber yang diinginkan tidak ditemukan di server. Tidak ada informasi untuk memberitahu pengguna apakah keadaan ini sementara atau permanen. Jika server menyadari situasi, the 410 Kod status harus digunakan untuk memberitahu sumber lama bahwa ia tidak tersedia secara permanen disebabkan beberapa mekanisme konfigurasi internal dan tidak ada alamat untuk melompat ke. The 404 Kod status digunakan secara luas apabila server tidak mau mengungkapkan alasannya permintaan ditolak atau tidak ada jawaban yang sesuai tersedia. |
| 405 | Metode permintaan yang dispecifikasikan di baris permintaan tidak dapat digunakan untuk meminta sumber daya yang sesuai. Tanggapan harus mengembalikan header 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 dipinta tidak memenuhi kondisi di header permintaan, sehingga entitas tanggapan tidak dapat dibuat. kecuali ini adalah 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 di Content-Header jenis. 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 mengotentikasi di server proksi. Server proksi harus mengembalikan tanggapan Proksi-Otentikasi untuk otentikasi. Sisi klien dapat mengembalikan tanggapan Proksi-Header pengesahan untuk otentikasi. Lihat RFC 2617. |
| 408 | Permintaan melebihi waktu. Sisi klien tidak dapat menyelesaikan pengiriman permintaan dalam waktu sisi server siap menunggu. Sisi klien dapat mengirimkan permintaan kembali kapan saja tanpa perubahan apapun. |
| 409 | Pemintaan tidak dapat diselesaikan disebabkan konflik dengan keadaan sumber daya yang dipinta saat ini. 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-dikemukakan persekitaran yang dipertahankan, jika maklumat versi yang disambungkan ke PUT-permintaan perubahan yang diserahkan untuk sumber tertentu bertentangan dengan sebelumnya (kedua-tiga)-permintaan pihak (kedua) pihak, pelayan seharusnya mengembalikan 409 kesalahan memberitahu pengguna bahawa permintaan tidak dapat selesai.
Pada masa ini, entiti balasan mungkin mengandungi perbandingan perbezaan antara dua versi yang bertentangan, supaya pengguna boleh menghantar semula versi yang disatukan. |
| 410 | Sumber permintaan yang diminta tidak lagi tersedia di pelayan dan tidak ada alamat pengalihan yang diketahui. Keadaan ini seharusnya dianggap kekal. Jika mungkin, pihak kiri dengan keupayaan mengedit pautan seharusnya menghapuskan semua rujukan ke alamat ini dengan keizinan pengguna. Jika pelayan tidak tahu atau tidak dapat menentukan sama ada keadaan ini adalah kekal, maka seorang 404 kod status seharusnya digunakan. Jika tidak disifatkan secara lain, balasan ini boleh disimpan di pustaka. Tujuannya adalah 410 balasan utamanya adalah untuk membantu pemilik laman web memelihara laman, untuk memberitahu pengguna bahawa sumber tersebut tidak lagi tersedia, dan pemilik pelayan mahu semua sambungan jauh ke sumber ini dipadamkan.
Jenis peristiwa ini umum dalam masa-batasan, nilai-perkhidmatan ditambahkan. Sama seperti, 410 balasan digunakan untuk memberitahu pihak kiri bahawa sumber yang asalnya milik individu tersebut tidak lagi tersedia di laman pelayan semasa. Tentu saja, ia sepenuhnya tergantung kepada pemilik pelayan untuk menandakan semua sumber yang tidak lagi tersedia secara kekal sebagai' 410 Gone ', dan berapa lama untuk mempertahankan tanda ini. |
| 411 | Pelayan menolak untuk menerima permintaan tanpa menentukan penggaris panjang konten.-Penghantaran penggaris panjang.-Penghantaran penggaris panjang yang menunjukkan panjang badan permintaan, pihak kiri boleh menghantar permintaan sekali lagi. |
| 412 | Pelayan gagal memenuhi satu atau lebih kelayakan semasa mengesahkan mereka diberikan dalam medan header permintaan. Kod status ini memungkinkan pihak klien untuk menetapkan kelayakan dalam metadata yang diminta (data medan header permintaan) semasa mengambil sumber, untuk menghalang kaedah permintaan daripada diterapkan kepada sumber yang lain daripada yang dikehendaki. |
| 413 | Pelayan menolak untuk memproses permintaan semasa kerana permintaan menghantar lebih banyak data entiti daripada yang diinginkan atau boleh ditangani pelayan. Dalam kes ini, pelayan boleh menutup sambungan untuk mencegah pihak klien untuk terus menghantar permintaan. Jika situasi ini sementara, pelayan seharusnya mengembalikan kod Ulangkaji-Sebagai penghujung header untuk memberitahu bahawa masa yang boleh cuba lagi daripada pihak klien. |
| 414 | URI yang diminta lebih lama daripada yang boleh diuraikan pelayan, jadi pelayan menolak untuk memproses permintaan. Ini jarang, dan kes biasa termasuk: Penghantaran borang yang sepatutnya digunakan kaedah POST menjadi kaedah GET, mengakibatkan string kerusi (Query String) terlalu lama. Redirect URI "hantu", seperti setiap pengalihan menggunakan URI lama sebagai sebahagian daripada URI baru, mengakibatkan URI terlalu lama selepas beberapa pengalihan. Klien sedang mencuba untuk menyerang pelayan dengan bug keamanan yang wujud di beberapa pelayan.
Tipe pelayan ini menggunakan-buffer panjang untuk membaca atau manipulasi URI yang diminta. Kapan parameter selepas GET melebihi nilai tertentu, kebanjiran buffer boleh terjadi, mengakibatkan eksekusi kod acak [1]. Pelayan tanpa kelemahan seperti itu seharusnya mengembalikan 414 kod status. |
| 415 | Untuk kaedah permintaan semasa dan sumber sediaan yang diminta, entiti yang diserahkan dalam permintaan bukan dalam format yang disokong oleh pelayan, jadi permintaan disampaikan balik. |
| 416 | Jika permintaan mengandungi penghujung Range, dan sebarang kawasan data yang ditentukan dalam Range tidak sepadan dengan kawasan yang tersedia sumber sediaan semasa, dan If-Penghujung header tiada dalam permintaan, pelayan seharusnya mengembalikan 416 kode status. Jika Range menggunakan rentang byte, situasi ini berarti bahwa posisi byte pertama dari semua rentang data yang disebutkan dalam permintaan melebihi panjang sumber daya saat ini. Pelayan seharusnya juga termasuk Content-tajuk entitas Range bersama dengan 416 kode status untuk menunjukkan panjang sumber daya saat ini. Tanggapan ini juga dilarang untuk menggunakan multipart/byteranges sebagai kontennya-Type. |
| 417 | Konten yang diharapkan yang disebutkan di tajuk permintaan Expect tidak dapat dipenuhi oleh pelayan, atau pelayan adalah proksi pelayan yang memiliki bukti yang jelas bahwa konten yang diharapkan tidak dapat dipenuhi di node berikutnya di jalur saat ini. |
| 421 | Jumlah koneksi ke pelayan dari Alamat Protokol Internet tempat sisi klien saat ini berada melebihi maksimum yang diijinkan oleh pelayan. Biasanya, Alamat Protokol Internet di sini merujuk kepada alamat sisi klien yang dilihat dari pelayan (seperti alamat penghubung atau proksi pengguna). Dalam kasus ini, jumlah koneksi dapat melibatkan lebih dari satu pengguna akhir. |
| 422 | Jumlah koneksi ke pelayan dari Alamat Protokol Internet tempat sisi klien saat ini berada melebihi maksimum yang diijinkan oleh pelayan. Biasanya, Alamat Protokol Internet di sini merujuk kepada alamat sisi klien yang dilihat dari pelayan (seperti alamat penghubung atau proksi pengguna). Dalam kasus ini, jumlah koneksi dapat melibatkan lebih dari satu pengguna akhir. |
| 422 | Permintaan yang dibuat dengan format yang benar, tetapi tidak dapat dijawab karena kesalahan semantik. (RFC 4918 WebDAV) 423 Dikunci Sumber daya saat ini sedang dikunci. (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 Berurutan 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 | Pelayan menghadapi situasi yang tak terduga yang menghalangi penyelesaian permintaan. Secara umum, masalah ini terjadi ketika kode pelayan gagal. |
| 501 | Pelayan tidak mendukung fitur yang diperlukan oleh permintaan saat ini. Ketika pelayan tidak dapat mengenali metode permintaan yang diminta dan tidak dapat mendukung permintaannya untuk sumber daya apapun. |
| 502 | Saat pelayan yang bekerja sebagai penghubung atau proksi mencoba melaksanakan permintaan, dia menerima tanggapan yang tidak sah dari pelayan yang di atas. |
| 503 | Server saat ini tidak dapat memproses permintaan karena pemeliharaan sementara server atau kelebihan beban. Kondisi ini sementara dan akan pulih setelah beberapa waktu. Jika waktu penundaan dapat diprediksi, tanggapan dapat termasuk Retry-Setelah header untuk menunjukkan waktu penundaan. Jika ini Retry-Setelah informasi tidak diberikan, sisi klien harus mengelola hal itu seperti jika itu adalah 500 tanggapan. Catatan: Ada 503 kode status yang tidak berarti bahwa server harus menggunakannya dalam keadaan kelebihan beban. Beberapa server hanya ingin menolak koneksi klien. |
| 504 | Ketika server yang bekerja sebagai gateway atau proxy mencoba melaksanakan permintaan, ia gagal menerima tanggapan dari server yang diunggulkan (dikenali melalui URI, seperti HTTP, FTP, LDAP) atau server sekunder (seperti DNS) dalam jangka waktu yang pantas. Catatan: Beberapa server proxy kembali 400 atau 5kesalahan 00 ketika permintaan DNS keluar batas waktu |
| 505 | Server tidak mendukung, atau menolak untuk mendukung, versi HTTP yang digunakan dalam permintaan. Ini mengimplikasikan bahwa server tidak dapat atau tidak akan menggunakan versi yang sama seperti sisi klien. Respon harus termasuk entitas yang menjelaskan mengapa versi tersebut tidak didukung dan protokol yang didukung oleh server. |
| 506 | Diperpanjang oleh Protokol Negosiasi Konten Transparan (RFC 2295), ini merepresentasikan kesalahan konfigurasi internal di server: variabel negosiasi sumber daya yang diminta diatur untuk menggunakan dirinya sendiri dalam negosiasi konten yang transparan, dan karena itu bukan titik fokus yang sesuai dalam proses negosiasi. |
| 507 | Server tidak dapat menyimpan konten yang diperlukan untuk menyelesaikan permintaan. Kondisi ini dianggap sementara. WebDAV (RFC 4918) |
| 509 | Server telah mencapai batas lebar jalur. Ini bukan kode status resmi, tetapi masih digunakan secara luas. |
| 510 | Pemegang kebijakan yang diperlukan untuk mendapatkan sumber daya belum terpenuhi. (RFC 2774) |
