| Kode Status HTTP |
Makna Kode |
| 100 |
Klien harus terus mengirimkan permintaan. Respons sementara ini digunakan untuk memberi tahu klien bahwa sebagian dari permintaannya telah diterima oleh server, dan belum ditolak. Klien harus terus mengirimkan bagian sisa dari permintaan tersebut, atau jika permintaan telah selesai, abaikan respons ini. Server harus mengirimkan respons akhir kepada klien setelah permintaan selesai. |
| 101 |
Server telah memahami permintaan klien dan akan memberi tahu klien untuk menggunakan protokol berbeda untuk menyelesaikan permintaan ini melalui header Upgrade. Setelah mengirimkan baris kosong terakhir dari respons ini, server akan beralih ke protokol yang ditentukan dalam header Upgrade. Hanya saat berpindah ke protokol baru lebih menguntungkan harus langkah serupa diambil. Misalnya, beralih ke versi HTTP baru lebih menguntungkan daripada versi lama, atau beralih ke protokol waktu nyata dan sinkron untuk mentransfer sumber daya yang memanfaatkan fitur semacam itu. |
| 102 |
Kode status yang diperluas oleh WebDAV (RFC 2518), menunjukkan bahwa pemrosesan akan dilanjutkan. |
| 200 |
Permintaan berhasil, header respons atau body data yang diharapkan akan disertakan dalam respons ini. |
| 201 |
Permintaan telah berhasil dilaksanakan, dan sumber daya baru telah dibuat sesuai dengan permintaan, dan URI-nya telah dikembalikan bersama header Location. Jika sumber daya yang diminta tidak dapat segera dibuat, maka harus mengembalikan '202 Diterima'. |
| 202 |
Server telah menerima permintaan tetapi belum memprosesnya. Seperti yang mungkin telah ditolak, permintaan tersebut mungkin dan mungkin tidak dijalankan pada akhirnya. Dalam kasus operasi asinkron, tidak ada cara yang lebih mudah daripada mengirimkan kode status ini. Respons yang mengembalikan kode status 202 bertujuan untuk memungkinkan server menerima permintaan untuk proses lain (misalnya, operasi berbasis batch yang hanya dijalankan sekali sehari), tanpa harus menjaga koneksi klien dengan server sampai semua operasi batch selesai. Dalam menerima proses permintaan dan mengembalikan respons dengan status 202 harus menyertakan informasi mengenai status pemrosesan saat ini dalam entitas yang dikembalikan, serta memberi petunjuk kepada pemantau status atau perkiraan status, sehingga pengguna dapat memperkirakan apakah operasi telah selesai. |
| 203 |
Server berhasil memproses permintaan, tetapi header entitas yang dikembalikan bukan merupakan set definitif yang valid di server asli, melainkan salinan dari lokal atau pihak ketiga. Informasi saat ini mungkin merupakan subset atau superset dari versi asli. Misalnya, metadata tentang sumber daya mungkin menyebabkan server asli mengetahui bahwa metadata tersebut adalah super. Menggunakan kode status ini tidaklah wajib, dan hanya sesuai jika respons yang tidak menggunakan kode status ini akan mengembalikan 200 OK. |
| 204 |
Server berhasil memproses permintaan, tetapi tidak perlu mengembalikan isi entitas apapun, dan diharapkan mengembalikan metadata yang diperbarui. Respons mungkin mengembalikan metadata baru atau yang diperbarui dalam bentuk header entitas. Jika header tersebut ada, maka harus sesuai dengan variabel yang diminta. Jika klien adalah browser, maka browser pengguna harus mempertahankan halaman yang mengirimkan permintaan tanpa perubahan dalam tampilan dokumen, meskipun sesuai dengan spesifikasi metadata baru atau yang diperbarui harus diterapkan pada tampilan dokumen aktif di browser pengguna. Karena respons 204 dilarang mengandung body pesan, maka selalu diakhiri dengan baris kosong pertama setelah header pesan. |
| 205 |
Server berhasil memproses permintaan dan tidak mengembalikan konten apapun. Namun, berbeda dengan respons 204, respons yang mengembalikan kode status ini meminta pemohon untuk mereset tampilan dokumen. Respons ini terutama digunakan untuk mereset formulir segera setelah menerima input pengguna, agar pengguna dapat dengan mudah memulai input lain. Seperti respons 204, respons ini juga dilarang mengandung body pesan dan diakhiri dengan baris kosong pertama setelah header pesan. |
| 206 |
Server telah berhasil memproses permintaan GET sebagian. Seperti alat unduh HTTP seperti FlashGet atau Xunlei menggunakan respons semacam ini untuk mendukung unduhan titik pemulihan atau membagi dokumen besar menjadi beberapa bagian unduhan yang diunduh secara bersamaan. Permintaan ini harus menyertakan header Range untuk menunjukkan rentang konten yang diinginkan oleh klien dan mungkin menyertakan If-Range sebagai kondisi permintaan. Respons harus menyertakan domain header berikut: Content-Range untuk menunjukkan rentang konten yang dikembalikan dalam respons ini; jika Content-Type adalah multipart/byteranges untuk unduhan multi-segment, maka setiap bagian multipart juga harus menyertakan domain Content-Range untuk menunjukkan rentang konten dari bagian tersebut. Jika respons menyertakan Content-Length, maka nilainya harus mencocokkan jumlah byte yang sebenarnya dari rentang konten yang dikembalikan. Date ETag dan/atau Content-Location, jika permintaan yang sama seharusnya mengembalikan respons 200. Expires, Cache-Control, dan/atau Vary, jika nilainya mungkin berbeda dari nilai respons lain yang sesuai dengan variabel yang sebelumnya. Jika permintaan respons ini menggunakan If-Range untuk verifikasi cache kuat, maka respons ini tidak boleh menyertakan header entitas lain; jika permintaan respons ini menggunakan If-Range untuk verifikasi cache lemah, maka respons ini dilarang menyertakan header entitas lain; ini menghindari inkonsistensi antara konten entitas yang di-cache dan header entitas yang telah diperbarui. Jika tidak, respons ini harus menyertakan semua domain header entitas yang seharusnya dikembalikan dalam respons 200. Jika header ETag atau Last-Modified tidak cocok secara tepat, maka cache klien diperintahkan untuk tidak menggabungkan konten respons 206 dengan konten yang sudah di-cache sebelumnya. Semua cache yang tidak mendukung header Range dan Content-Range dilarang meng-cache konten respons 206. |
| 207 |
Kode status yang diperluas oleh WebDAV (RFC 2518), menunjukkan bahwa tubuh pesan selanjutnya akan berupa pesan XML, dan mungkin mencakup serangkaian kode respons independen berdasarkan jumlah sub-permintaan sebelumnya. |
| 300 |
Sumber daya yang diminta memiliki serangkaian umpan balik yang dapat dipilih, masing-masing dengan alamat spesifik dan informasi iklan yang dipicu dari peramban. Pengguna atau browser dapat memilih alamat preferensi untuk melakukan pengalihan. Kecuali jika ini adalah permintaan HEAD, respons ini harus mencakup entitas yang berisi daftar karakteristik dan alamat sumber daya untuk memungkinkan pengguna atau browser memilih alamat pengalihan yang paling sesuai. Format entitas tersebut ditentukan oleh format yang didefinisikan dalam Content-Type. Browser mungkin secara otomatis membuat pilihan yang paling sesuai berdasarkan format respons dan kemampuan browser itu sendiri. Tentu saja, spesifikasi RFC 2616 tidak merinci bagaimana pilihan otomatis semacam itu seharusnya dilakukan. Jika server itu sendiri sudah memiliki pilihan umpan balik yang diutamakan, maka URI umpan balik tersebut harus ditunjukkan dalam Location; browser mungkin menggunakan nilai Location tersebut sebagai alamat pengalihan otomatis. Selain itu, kecuali ada ketentuan tambahan, respons ini juga dapat di-cache. |
| 301 |
Sumber daya yang diminta telah berpindah secara permanen ke lokasi baru dan semua referensi ke sumber daya ini di masa depan harus menggunakan salah satu dari beberapa URI yang dikembalikan dalam respons ini. Jika memungkinkan, klien dengan fungsi pengeditan tautan harus secara otomatis memodifikasi alamat permintaan ke alamat yang dikembalikan oleh server. Kecuali ada ketentuan tambahan, respons ini juga dapat di-cache. URI permanen yang baru harus dikembalikan dalam domain Location respons. Kecuali ini adalah permintaan HEAD, maka entitas respons harus menyertakan hyperlink ke URI baru dan penjelasan singkat. Jika ini bukan permintaan GET atau HEAD, maka peramban dilarang melakukan pengalihan otomatis, kecuali mendapatkan konfirmasi dari pengguna karena kondisi permintaan mungkin berubah. Catatan: untuk beberapa browser yang menggunakan protokol HTTP/1.0, ketika permintaan POST yang mereka kirimkan mendapat respons 301, permintaan pengalihan yang akan datang akan berubah menjadi metode GET. |
| 302 |
Sumber daya yang diminta sekarang sementara merespons permintaan dari URI yang berbeda. Karena pengalihan semacam ini bersifat sementara, klien harus terus mengirimkan permintaan ke alamat lama. Respons ini hanya dapat di-cache jika ditentukan dalam Cache-Control atau Expires. URI sementara yang baru harus dikembalikan dalam domain Location respons. Kecuali ini adalah permintaan HEAD, entitas respons harus menyertakan hyperlink ke URI baru dan penjelasan singkat. Jika ini bukan permintaan GET atau HEAD, maka peramban dilarang melakukan pengalihan otomatis, kecuali mendapatkan konfirmasi dari pengguna karena kondisi permintaan mungkin berubah. Catatan: meskipun spesifikasi RFC 1945 dan RFC 2068 tidak mengizinkan klien mengubah metode permintaan saat melakukan pengalihan, banyak browser yang ada saat ini memperlakukan respons 302 sebagai 303 dan menggunakan metode GET untuk mengakses URI yang ditentukan dalam Location, tanpa memperhatikan metode permintaan asal. Kode status 303 dan 307 telah ditambahkan untuk secara jelas mengharapkan jenis reaksi yang diinginkan dari klien oleh server. |
| 303 |
Respons untuk permintaan saat ini dapat ditemukan di URI lain, dan klien harus mengakses sumber daya itu dengan metode GET. Metode ini ada terutama untuk memungkinkan pengalihan output dari permintaan POST yang diaktifkan oleh skrip ke sumber daya baru. URI baru ini bukan pengganti dari sumber daya asli. Di samping itu, respons 303 dilarang untuk di-cache. Tentu saja, permintaan kedua (pengalihan) dapat di-cache. URI baru harus dikembalikan dalam domain Location respons. Kecuali ini adalah permintaan HEAD, entitas respons harus menyertakan hyperlink ke URI baru dan penjelasan singkat. Catatan: Banyak browser sebelum versi HTTP/1.1 tidak dapat memahami status 303 dengan benar. Jika interaksi dengan browser tersebut perlu dipertimbangkan, kode status 302 seharusnya cukup baik, karena sebagian besar browser menangani respons 302 sesuai dengan cara yang diperlukan oleh spesifikasi untuk klien menangani respons 303. |
| 304 |
Jika klien mengirimkan permintaan GET bersyarat dan permintaan tersebut diizinkan, dan konten dokumen (sejak kunjungan terakhir atau sesuai dengan kondisi permintaan) tidak berubah, maka server harus mengembalikan kode status ini. Respons 304 dilarang mencantumkan body pesan, sehingga selalu diakhiri dengan baris kosong pertama setelah header pesan. Respons ini harus mencantumkan header berikut: Date, kecuali jika server ini tidak memiliki jam. Jika server tanpa jam juga mengikuti aturan ini, maka server proxy dan klien dapat menambahkan field Date ke header respons yang diterima (seperti yang ditentukan dalam RFC 2068) dan mekanisme cache akan bekerja dengan baik. ETag dan/atau Content-Location, jika permintaan yang sama seharusnya mengembalikan respons 200. Expires, Cache-Control, dan/atau Vary, jika nilainya mungkin berbeda dari nilai respons lain yang sesuai dengan variabel yang sebelumnya. Jika permintaan respons ini menggunakan verifikasi cache yang kuat, maka respons ini tidak boleh menyertakan header entitas lain; jika tidak (misalnya, permintaan GET bersyarat menggunakan verifikasi cache yang lemah), maka respons ini dilarang menyertakan header entitas lain; ini menghindari ketidaksesuaian antara konten entitas yang di-cache dan header entitas yang telah diperbarui. Jika respons 304 menunjukkan bahwa suatu entitas saat ini tidak di-cache, maka sistem cache harus mengabaikan respons ini dan mengulangi pengiriman permintaan tanpa batasan. Jika menerima respons 304 untuk memperbarui suatu entitas cache, maka sistem cache harus memperbarui seluruh entitas untuk mencerminkan semua nilai bidang yang diperbarui dalam respons. |
| 305 |
Sumber daya yang diminta harus diakses melalui proxy yang ditentukan. Domain Location akan memberikan informasi URI di mana proxy yang ditentukan berada; penerima harus mengirimkan permintaan terpisah untuk mengakses sumber daya yang sesuai melalui proxy ini. Hanya server asli yang dapat menghasilkan respons 305. Catatan: RFC 2068 tidak secara eksplisit menyatakan bahwa respons 305 adalah untuk mengalihkan permintaan terpisah, dan hanya dapat dihasilkan oleh server asli. Mengabaikan batasan tersebut mungkin mengakibatkan konsekuensi keamanan yang serius. |
| 306 |
Dalam spesifikasi terbaru, kode status 306 tidak lagi digunakan. |
| 307 |
Sumber daya yang diminta sekarang sementara merespons permintaan dari URI yang berbeda. Karena pengalihan semacam ini bersifat sementara, klien harus terus mengirimkan permintaan ke alamat lama. Respons ini hanya dapat di-cache jika ditentukan dalam Cache-Control atau Expires. URI sementara yang baru harus dikembalikan dalam domain Location respons. Kecuali ini adalah permintaan HEAD, maka entitas respons harus menyertakan hyperlink ke URI baru dan penjelasan singkat. Karena beberapa browser mungkin tidak mengenali respons 307, maka informasi tambahan yang diperlukan harus ditambahkan agar pengguna memahami dan dapat mengirimkan permintaan ke URI baru. Jika ini bukan permintaan GET atau HEAD, maka peramban dilarang melakukan pengalihan otomatis, kecuali mendapatkan konfirmasi dari pengguna karena kondisi permintaan mungkin berubah. |
| 400 |
1. Terdapat kesalahan semantik, permintaan saat ini tidak dapat dipahami oleh server. Klien tidak seharusnya mengirimkan permintaan ini lagi tanpa modifikasi. 2. Parameter permintaan salah. |
| 401 |
Permintaan ini memerlukan autentikasi pengguna. Respons ini harus mencantumkan header WWW-Authenticate yang sesuai untuk meminta informasi pengguna. Klien dapat mengulangi permintaan dengan menyertakan header Authorization yang sesuai. Jika permintaan saat ini sudah mencantumkan sertifikat Authorization, maka respons 401 menandakan bahwa server telah menolak verifikasi untuk sertifikat tersebut. Jika respons 401 mencakup permintaan verifikasi yang sama dengan respons sebelumnya, dan browser telah setidaknya mencoba verifikasi sekali, maka browser harus menampilkan informasi entitas yang terdapat dalam respons, karena informasi ini mungkin mengandung informasi diagnosis yang relevan. Lihat RFC 2617. |
| 402 |
Kode status ini disediakan untuk kemungkinan kebutuhan di masa depan. |
| 403 |
Server telah memahami permintaan tetapi menolak untuk mengeksekusinya. Berbeda dengan respons 401, autentikasi tidak akan membantu, dan permintaan ini tidak seharusnya dikirim ulang. Jika ini bukan permintaan HEAD, dan server ingin menjelaskan mengapa permintaan tidak bisa dieksekusi, maka harus ada deskripsi alasan penolakan dalam entitas. Tentu saja, server juga dapat mengembalikan respons 404, jika tidak ingin memberikan informasi apapun kepada klien. |
| 404 |
Permintaan gagal, sumber daya yang diharapkan tidak ditemukan di server. Tidak ada informasi yang dapat memberitahu pengguna apakah situasi ini bersifat sementara atau permanen. Jika server mengetahui kondisi tersebut, maka harus menggunakan kode status 410 untuk memberi tahu bahwa sumber daya lama sudah tidak tersedia karena beberapa masalah konfigurasi internal, dan tidak ada alamat pengalihan. Kode status 404 ini banyak digunakan ketika server tidak ingin mengungkapkan alasan mengapa permintaan ditolak atau tidak memiliki respons lain yang sesuai. |
| 405 |
Metode permintaan yang ditentukan dalam baris permintaan tidak dapat digunakan untuk permintaan sumber daya yang sesuai. Respons ini harus mengembalikan header Allow untuk menunjukkan daftar metode permintaan yang dapat diterima oleh sumber daya saat ini. Mengingat metode PUT dan DELETE akan melakukan operasi tulis pada sumber daya di server, sebagian besar server web tidak mendukung atau tidak mengizinkan metode permintaan tersebut dalam konfigurasi default, sehingga akan mengembalikan kesalahan 405 untuk permintaan semacam itu. |
| 406 |
Karakteristik konten sumber daya yang diminta tidak dapat memenuhi kondisi dalam header permintaan, sehingga tidak dapat menghasilkan respons entitas. Kecuali ini adalah permintaan HEAD, respons ini harus mengembalikan entitas yang mencakup daftar karakteristik entitas dan alamat yang dapat dipilih oleh pengguna atau browser. Format entitas ditentukan oleh tipe media yang didefinisikan dalam header Content-Type. Browser dapat membuat pilihan terbaik berdasarkan format dan kapasitas mereka sendiri. Namun, spesifikasi tidak mendefinisikan standar untuk membuat pilihan otomatis semacam itu. |
| 407 |
Mirip dengan respons 401, hanya saja klien harus melakukan autentikasi di server proxy. Server proxy harus mengembalikan Proxy-Authenticate untuk menanyakan identitas. Klien dapat mengembalikan header Proxy-Authorization untuk autentikasi. Lihat RFC 2617. |
| 408 |
Permintaan telah habis waktu. Klien tidak menyelesaikan pengiriman permintaan dalam waktu yang ditentukan oleh server. Klien dapat mengirimkan permintaan ini lagi kapan saja tanpa melakukan perubahan. |
| 409 |
Permintaan tidak dapat diselesaikan karena ada bentrokan dengan status sumber daya yang diminta saat ini. Kode ini hanya diperbolehkan digunakan dalam situasi di mana pengguna dianggap dapat menyelesaikan bentrokan ini dan akan mengirimkan permintaan baru. Respons ini harus memiliki cukup informasi agar pengguna dapat menemukan sumber bentrok tersebut. Bentrokan sering terjadi dalam pemrosesan permintaan PUT. Misalnya, dalam lingkungan di mana terdapat pemeriksaan versi, permintaan perubahan tertentu pada sumber daya yang dilampirkan informasi versi mungkin mengalami bentrokan dengan permintaan sebelumnya (dari pihak ketiga), sehingga server harus mengembalikan kesalahan 409 dan memberi tahu pengguna bahwa permintaan tidak dapat diselesaikan. Dalam kasus ini, isi respons mungkin mencakup perbandingan perbedaan antara dua versi yang bertentangan, agar pengguna dapat mengirimkan versi baru yang digabungkan. |
| 410 |
Sumber daya yang diminta sudah tidak tersedia di server, dan tidak ada alamat pengalihan yang diketahui. Situasi ini harus dianggap permanen. Jika memungkinkan, klien yang memiliki kemampuan mengedit tautan harus menghapus semua referensi ke alamat ini setelah mendapatkan izin dari pengguna. Jika server tidak tahu atau tidak dapat menentukan apakah situasi ini permanen, maka harus menggunakan kode status 404. Kecuali ditentukan lain, respons ini dapat di-cache. Respons 410 bertujuan untuk membantu administrator situs web dalam memelihara situs web, memberi tahu pengguna bahwa sumber daya tidak lagi tersedia, dan pemilik server berharap semua koneksi eksternal yang mengarah ke sumber daya tersebut juga dihapus. Peristiwa semacam ini umum terjadi dalam layanan berbasis waktu yang terbatas atau berbasis nilai tambah. Demikian pula, respons 410 juga digunakan untuk memberi tahu klien bahwa sumber daya yang dulunya menjadi hak milik seseorang sudah tidak tersedia di situs server saat ini. Tentu saja, perlu dipertimbangkan apakah semua sumber daya yang tidak lagi tersedia harus ditandai sebagai '410 Hilang' dan seberapa lama tanda ini harus dipertahankan, sepenuhnya tergantung pada pemilik server. |
| 411 |
Server menolak untuk menerima permintaan tanpa header Content-Length yang terdefinisi. Setelah header Content-Length yang valid yang menunjukkan panjang body permintaan ditambahkan, klien dapat mengirimkan permintaan ini lagi. |
| 412 |
Server tidak dapat memenuhi satu atau lebih syarat yang diberikan dalam header permintaan. Kode status ini memungkinkan klien untuk menetapkan syarat dalam data metadata permintaan (data header) saat mengambil sumber daya, untuk mencegah metode permintaan diterapkan pada sumber daya yang diinginkan. |
| 413 |
Server menolak untuk memproses permintaan saat ini karena data entitas yang dikirimkan terlalu besar untuk diproses oleh server. Dalam situasi ini, server dapat menutup koneksi untuk mencegah klien melanjutkan pengiriman permintaan ini. Jika situasinya bersifat sementara, server harus mengembalikan respons dengan header Retry-After untuk memberi tahu klien setelah berapa lama mereka dapat mencoba lagi. |
| 414 |
Panjang URI yang diminta melebihi batas yang dapat dipahami server, sehingga server menolak untuk melayani permintaan tersebut. Ini cukup jarang, kondisi umumnya meliputi: pengiriman formulir yang seharusnya menggunakan metode POST menjadi metode GET, sehingga string kueri (Query String) menjadi terlalu panjang. URI pengalihan "black hole", misalnya, setiap kali pengalihan mengubah URI lama menjadi bagian dari URI baru, menghasilkan URI yang terlalu panjang setelah beberapa pengalihan. Klien sedang mencoba menggunakan beberapa kerentanan keamanan di server tertentu untuk menyerang server. Server semacam ini menggunakan pembacaan buffer dengan panjang tetap untuk membaca atau memproses URI permintaan, yang mungkin menyebabkan buffer overflow dan eksekusi kode arbitrer setelah jumlah parameter GET melebihi angka tertentu. Server tanpa kerentanan semacam ini seharusnya mengembalikan kode status 414. |
| 415 |
Entitas yang dikirimkan dalam permintaan tidak sesuai dengan format yang didukung oleh server untuk metode permintaan saat ini dan sumber daya yang diminta, sehingga permintaan ditolak. |
| 416 |
Jika permintaan mencakup header Range, dan data range yang ditentukan tidak memiliki kesesuaian dengan rentang yang tersedia dari sumber daya saat ini, dan permintaan tidak menetapkan header If-Range, maka server harus mengembalikan kode status 416. Jika Range menggunakan rentang byte, maka situasi tersebut menunjukkan bahwa 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 bersama dengan pengembalian kode status 416, untuk menunjukkan panjang sumber daya saat ini. Respons ini juga dilarang menggunakan multipart/byteranges sebagai Content-Type. |
| 417 |
Konten yang diharapkan yang ditentukan dalam header permintaan Expect tidak dapat dipenuhi oleh server, atau server tersebut merupakan server proxy yang memiliki bukti yang jelas bahwa konten Expect tidak dapat dipenuhi di titik berikutnya dari rute saat ini. |
| 421 |
Jumlah koneksi dari alamat IP klien saat ini ke server melebihi batas maksimum yang diizinkan oleh server. Umumnya, alamat IP di sini merujuk pada alamat klien yang terlihat dari server (misal, alamat gateway atau alamat server proxy pengguna). Dalam kasus ini, perhitungan jumlah koneksi mungkin melibatkan lebih dari satu pengguna akhir. |
| 422 |
Format permintaan benar, tetapi tidak dapat direspons karena mengandung kesalahan semantik. (RFC 4918 WebDAV) 423 Terkunci sumber daya saat ini terkunci. (RFC 4918 WebDAV) |
| 424 |
Permintaan saat ini gagal karena kesalahan dalam permintaan sebelumnya, seperti PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definisi dalam draf koleksi tingkat lanjut WebDav, tetapi tidak muncul dalam Protokol Set Order WebDAV (RFC 3658). |
| 426 |
Klien harus beralih ke TLS/1.0. (RFC 2817) |
| 449 |
Diperluas oleh Microsoft, menunjukkan bahwa permintaan harus diulang setelah tindakan yang sesuai dilakukan. |
| 500 |
Server menemui keadaan yang tidak terduga yang menyebabkannya tidak dapat menyelesaikan pemrosesan permintaan. Umumnya, masalah ini muncul ketika ada kesalahan dalam kode program server. |
| 501 |
Server tidak mendukung fungsi yang diperlukan untuk permintaan saat ini. Ketika server tidak dapat mengenali metode permintaan dan tidak dapat mendukung permintaan ke sumber daya apapun. |
| 502 |
Server yang berfungsi sebagai gateway atau proxy mendapat respons yang tidak valid saat mencoba melaksanakan permintaan dari server upstream. |
| 503 |
Server saat ini tidak dapat memproses permintaan karena pemeliharaan server sementara atau beban berlebih. Situasi ini bersifat sementara dan akan pulih setelah beberapa waktu. Jika waktu keterlambatan dapat diperkirakan, maka respons dapat mencakup header Retry-After untuk menunjukkan waktu keterlambatan tersebut. Jika tidak ada informasi Retry-After yang diberikan, maka klien harus memperlakukannya seperti respons 500. Catatan: Keberadaan kode status 503 tidak berarti server harus menggunakannya ketika sedang mengalami beban berlebih. Beberapa server hanya ingin menolak koneksi dari klien. |
| 504 |
Server yang berfungsi sebagai gateway atau proxy gagal mendapatkan respons yang tepat tepat waktu dari server upstream (server yang diidentifikasi dengan URI, misalnya HTTP, FTP, LDAP) atau server sekunder (seperti DNS). Catatan: beberapa server proxy mungkin mengembalikan kesalahan 400 atau 500 ketika query DNS mengalami timeout. |
| 505 |
Server tidak mendukung, atau menolak untuk mendukung versi HTTP yang digunakan dalam permintaan. Ini menunjukkan bahwa server tidak dapat atau tidak mau menggunakan versi yang sama dengan klien. Respons ini harus mencakup entitas yang menjelaskan mengapa versi tidak didukung dan protokol apa yang didukung oleh server. |
| 506 |
Diperluas oleh Protokol Negosiasi Konten Transparan (RFC 2295), menunjukkan bahwa ada kesalahan konfigurasi internal di server: variabel negosiasi yang diminta telah dikonfigurasi untuk digunakan dalam negosiasi konten transparan, sehingga tidak merupakan fokus yang tepat dalam pemrosesan negosiasi. |
| 507 |
Server tidak dapat menyimpan konten yang diperlukan untuk menyelesaikan permintaan. Status ini dianggap sementara. WebDAV (RFC 4918) |
| 509 |
Server mencapai batas bandwidth. Ini bukan kode status resmi, tetapi tetap banyak digunakan. |
| 510 |
Kebijakan yang diperlukan untuk mendapatkan sumber daya tidak dipenuhi. (RFC 2774) |