Alat Online
Kode Status Http Arti Kode Status
100 Klien harus terus mengirim permintaan. Tanggapan 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 Upgrade bahwa protokol yang berbeda digunakan untuk menyelesaikan permintaan. Setelah mengirimkan baris kosong terakhir dari respons, server akan beralih ke protokol yang ditentukan dalam header Upgrade. Hal ini hanya boleh dilakukan jika lebih menguntungkan untuk beralih ke protokol baru. Misalnya, beralih ke versi baru HTTP mungkin lebih menguntungkan daripada versi yang lebih lama, atau beralih ke protokol sinkron waktu nyata untuk mengirimkan sumber daya yang memanfaatkan fitur-fitur tersebut.
102 Kode status, yang diperluas oleh WebDAV (RFC 2518), mengindikasikan bahwa pemrosesan akan dilanjutkan.
200 Permintaan berhasil, dan header respons atau badan data yang diinginkan oleh permintaan akan dikembalikan bersama respons.
201 Permintaan telah dipenuhi dan sumber daya baru telah dibuat sebagai respons terhadap permintaan, dan URI-nya telah dikembalikan dengan header Lokasi. Jika sumber daya yang diminta tidak dapat dibuat tepat waktu, berikut ini akan dikembalikan'202 Accepted'。
202 Server telah menerima permintaan, tetapi belum memprosesnya. Sama seperti permintaan yang ditolak, permintaan tersebut mungkin akan dieksekusi atau tidak pada akhirnya. Dalam kasus operasi asinkron, tidak ada yang lebih nyaman daripada mengirimkan kode status ini. Tujuan mengembalikan respons 202 adalah untuk memungkinkan server menerima permintaan dari proses lain (seperti operasi berbasis batch yang dieksekusi hanya sekali sehari) tanpa klien harus mempertahankan koneksi ke server sampai operasi batch selesai. 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 atau belum.
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 yang asli. Sebagai contoh, metadata yang berisi sumber daya dapat menyebabkan server asal 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 tajuk ini ada, tajuk tersebut harus sesuai dengan variabel yang diminta. Jika klien adalah peramban, peramban pengguna HARUS mempertahankan halaman tempat permintaan dikirim tanpa perubahan apa pun pada tampilan dokumen, meskipun informasi meta yang baru atau yang diperbarui HARUS, menurut spesifikasi, 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 menangani permintaan dan tidak mengembalikan apa pun. Namun, 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 untuk memecah berkas besar menjadi beberapa pengunduhan sekaligus. Permintaan harus berisi header Range untuk menunjukkan kisaran konten yang ingin diterima klien, dan mungkin berisi If-Range sebagai kondisi permintaan. Respons harus berisi bidang header berikut: Rentang-Konten untuk menunjukkan cakupan konten yang dikembalikan dalam respons ini, atau, dalam kasus unduhan multi-bagian dengan Jenis-Konten multi-bagian/berkelompok, bidang Rentang-Konten di setiap segmen multi-bagian untuk menunjukkan cakupan konten di segmen tersebut. Jika respons berisi Panjang Konten, nilainya harus sesuai dengan jumlah byte yang sebenarnya dalam rentang konten yang dikembalikan. Kedaluwarsa, Cache-Control, dan/atau Vary, jika nilainya mungkin berbeda dari nilai respons sebelumnya dengan variabel yang sama. Respons ini tidak boleh berisi header entitas lain jika permintaan menggunakan validasi cache If-Range yang kuat, dan tidak boleh berisi header entitas lain jika permintaan menggunakan validasi cache If-Range yang lemah; 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 respons 200. Jika header ETag atau Last-Modified tidak sama persis, cache sisi klien harus melarang penggabungan konten yang dikembalikan dalam respons 206 dengan konten yang ditembolok sebelumnya. Tembolok apa pun yang tidak mendukung header Range dan Content-Range dilarang menembolok konten yang dikembalikan oleh respons 206.
207 Kode status yang diperluas oleh WebDAV(RFC 2518) Kode status, seperti yang diperluas oleh WebDAV, berarti bahwa badan pesan berikutnya akan berupa pesan XML dan mungkin berisi serangkaian kode respons terpisah, tergantung pada jumlah sub-permintaan sebelumnya.
300 Sumber daya yang diminta memiliki serangkaian respons alternatif, masing-masing dengan alamat spesifik dan informasi negosiasi yang digerakkan oleh peramban. Terserah kepada pengguna atau peramban untuk memilih alamat yang diinginkan untuk pengalihan. Kecuali jika ini adalah permintaan HEAD, respons harus menyertakan entitas yang merupakan daftar karakteristik sumber daya dan alamat yang dapat digunakan pengguna atau peramban untuk memilih alamat pengalihan yang paling tepat. 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 pemilihan otomatis ini harus dilakukan. Jika server itu sendiri telah memiliki opsi pengembalian yang disukai, URI dari pengembalian harus ditentukan dalam Lokasi; browser dapat menggunakan nilai Lokasi ini sebagai alamat untuk pengalihan otomatis. Selain itu, respons 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, peramban 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 hanya dapat ditembolok 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 selama pengalihan, banyak peramban yang ada memperlakukan respons 302 sebagai respons 303 dan menggunakan GET untuk mengakses URI yang ditentukan di 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 pengganti sumber daya asli. Selain itu, respons 303 tidak diizinkan 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 HTTP/1.1 tidak memahami status 303 dengan baik. Jika interaksi dengan browser ini perlu dipertimbangkan, kode status 302 seharusnya berfungsi, karena sebagian besar browser menangani respons 302 dengan cara yang sama seperti spesifikasi di atas yang mengharuskan klien menangani respons 303.
304 Kode status ini harus dikembalikan oleh server jika klien mengirimkan permintaan GET bersyarat dan permintaan tersebut diizinkan, dan konten dokumen tidak berubah (baik sejak kunjungan terakhir atau sesuai dengan kondisi permintaan). Respons 304 dilarang berisi badan pesan, dan oleh karena itu selalu diakhiri dengan baris kosong pertama setelah header pesan. Tanggapan harus berisi informasi 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 berfungsi dengan baik.ETag dan/atau Lokasi-Content, jika permintaan yang sama seharusnya mengembalikan respons 200. Kedaluwarsa, Cache-Control, dan/atau Vary, jika nilainya mungkin berbeda dari nilai respons sebelumnya dengan variabel yang sama. Jika permintaan respons menggunakan validasi cache yang kuat, maka respons tidak boleh berisi header entitas tambahan; jika tidak (misalnya, permintaan GET bersyarat menggunakan validasi cache yang lemah), respons dilarang berisi header entitas tambahan; hal ini untuk menghindari ketidakkonsistenan antara konten entitas yang di-cache dan informasi header 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 proxy yang ditentukan, dan 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 asal. 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 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. 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, kesalahan semantik, permintaan saat ini tidak dapat dipahami oleh server. Kecuali jika dimodifikasi, klien tidak boleh mengulangi permintaan. 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 mengirim ulang permintaan dengan 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 melakukan setidaknya satu kali percobaan autentikasi, maka peramban harus menunjukkan kepada pengguna informasi entitas yang terkandung dalam respons tersebut, 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 tersebut, tetapi menolak untuk menjalankannya. Tidak seperti respons 401, autentikasi tidak memberikan bantuan apa pun, dan permintaan tidak boleh dikirim ulang. Jika ini bukan permintaan HEAD, dan server ingin mengatakan mengapa permintaan tidak dapat dieksekusi, maka alasan penolakan harus dijelaskan dalam entitas. Tentu saja, server juga dapat mengembalikan respons 404 jika tidak ingin klien mendapatkan informasi apa pun.
404 Permintaan gagal, sumber daya yang diminta tidak ditemukan di server. Tidak ada informasi untuk memberi tahu pengguna apakah situasinya bersifat sementara atau permanen. Jika server mengetahui situasi tersebut, server harus menggunakan kode status 410 untuk memberi tahu server 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 mengindikasikan 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 atau 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 alamat yang dapat digunakan pengguna atau peramban untuk memilih karakteristik entitas yang paling sesuai. Format entitas ditentukan oleh jenis media yang ditentukan dalam header Tipe-Konten. Browser dapat membuat pilihan terbaik berdasarkan format dan kemampuannya sendiri. Namun, spesifikasi tidak mendefinisikan kriteria apa pun untuk membuat pilihan otomatis tersebut.
407 Mirip dengan respons 401, kecuali bahwa klien harus mengautentikasi dengan server proxy. Server proxy HARUS mengembalikan Proxy-Authenticate untuk interogasi identitas. Klien dapat mengembalikan header Otorisasi-Proksi untuk autentikasi. Lihat RFC 2617.
408 Batas waktu permintaan. Klien tidak menyelesaikan 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 sering terjadi dalam pemrosesan permintaan PUT. Misalnya, dalam lingkungan pengecekan versi, PUT yang dikirimkan untuk memodifikasi sumber daya tertentu dengan informasi versi yang bertentangan dengan permintaan (pihak ketiga) sebelumnya 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 yang telah digabungkan.
410 Sumber daya yang diminta tidak lagi tersedia di server dan tidak ada alamat penerusan yang diketahui. Situasi 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 tersebut permanen, maka kode status 404 harus digunakan. Kecuali ditentukan lain, respons ini dapat di-cache. Tujuan dari respons 410 terutama untuk membantu webmaster memelihara situs dengan memberi tahu pengguna bahwa sumber daya tidak lagi tersedia dan bahwa pemilik server ingin semua koneksi jarak jauh ke sumber daya juga dihapus. Jenis peristiwa ini biasa terjadi pada layanan bernilai tambah yang terbatas waktu. Demikian pula, respons 410 digunakan untuk memberi tahu klien bahwa sumber daya milik seseorang tidak lagi tersedia di situs server saat ini. Tentu saja, pertanyaan apakah semua sumber daya yang tidak tersedia secara permanen perlu ditandai seperti itu, dan berapa lama sumber daya tersebut harus dipertahankan seperti itu, juga penting.'410 Gone'， dan berapa lama harus dipertahankan sepenuhnya tergantung pada pemilik server.
411 Server menolak untuk menerima permintaan tanpa header Content-Length yang ditentukan. Klien dapat mengirim ulang permintaan setelah menambahkan header Content-Length yang valid yang menunjukkan panjang badan pesan permintaan.
412 Server gagal memenuhi satu atau beberapa prasyarat yang diberikan dalam bidang header permintaan saat memvalidasi permintaan. Kode status ini memungkinkan klien untuk menetapkan prasyarat dalam meta-informasi permintaan (data bidang header permintaan) saat mendapatkan sumber daya, sehingga mencegah metode permintaan diterapkan pada sumber daya selain konten yang diinginkannya.
413 Server menolak untuk memproses permintaan saat ini karena permintaan tersebut mengirimkan lebih banyak data fisik daripada yang dapat ditangani oleh server. Dalam kasus ini, server dapat menutup koneksi untuk mencegah klien melanjutkan pengiriman permintaan. Jika situasinya bersifat sementara, server harus mengembalikan header Retry-After untuk memberi tahu klien berapa lama waktu yang dibutuhkan untuk mencoba kembali.
414 URI permintaan lebih panjang daripada yang dapat ditafsirkan oleh server, sehingga server menolak untuk melayani permintaan. Hal ini jarang terjadi, dan biasanya terjadi ketika pengiriman formulir yang seharusnya menggunakan metode POST menjadi metode GET, sehingga menghasilkan Query String yang panjang. Redirect URI "lubang hitam", seperti menggunakan URI lama sebagai bagian dari URI baru untuk 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 yang diminta, yang dapat mengakibatkan buffer meluap ketika parameter GET melebihi nilai tertentu, yang menyebabkan eksekusi kode yang sewenang-wenang.[1]。 Server yang tidak memiliki kerentanan seperti itu akan 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 oleh server dan permintaan ditolak.
416 Jika permintaan berisi header permintaan Range, dan rentang data apa pun yang ditentukan dalam Range tidak sesuai dengan rentang yang tersedia untuk sumber daya saat ini, dan permintaan tidak mendefinisikan header permintaan If-Range, maka server harus mengembalikan kode status 416. Jika Range menggunakan rentang byte, maka ini berarti 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 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 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, lebih dari satu pengguna akhir mungkin terlibat dalam jumlah koneksi.
422 Jumlah koneksi dari alamat IP klien saat ini ke server 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, lebih dari satu pengguna akhir mungkin terlibat dalam penghitungan koneksi.
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) 423 Terkunci
424 Permintaan saat ini gagal karena kesalahan 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 yang dibutuhkan oleh permintaan saat ini. Ketika server tidak 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 Coba Lagi Setelah 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 bertindak sebagai gateway atau proxy yang mencoba melakukan permintaan tidak 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 apa 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 memenuhi permintaan. Kondisi ini dianggap bersifat sementara.WebDAV(RFC 4918)
509 Server mencapai batas bandwidth-nya. Ini bukan kode status resmi, tetapi masih banyak digunakan.
510 Kebijakan yang diperlukan untuk mendapatkan sumber daya belum terpenuhi. (RFC 2774)
Akses ke catatan: