| Kod Status HTTP |
Makna Kod Status |
| 100 |
Pelanggan harus meneruskan permintaan. Tindak balas sementara ini digunakan untuk memberitahu pelanggan bahawa sebahagian daripada permintaannya telah diterima oleh pelayan dan masih belum ditolak. Pelanggan harus meneruskan bahagian yang tinggal dari permintaan atau jika permintaan telah lengkap, mereka harus mengabaikan tindak balas ini. Pelayan harus menghantar tindak balas akhir kepada pelanggan setelah permintaan dilengkapkan. |
| 101 |
Pelayan sudah memahami permintaan pelanggan dan akan memberitahu pelanggan untuk menggunakan protokol yang berbeza untuk menyelesaikan permintaan ini dengan melalui header message Upgrade. Setelah menghantar baris kosong terakhir dari tindak balas ini, pelayan akan beralih kepada protokol yang ditentukan dalam header message Upgrade tersebut. Hanya langkah ini harus diambil apabila beralih kepada protokol baru memberikan lebih banyak keuntungan. Sebagai contoh, berpindah ke versi HTTP yang lebih baru yang lebih bermanfaat daripada yang lama, atau beralih ke protokol langsung dan segerak untuk menghantar sumber yang memanfaatkan ciri-ciri tersebut. |
| 102 |
Kod status yang dikembangkan oleh WebDAV (RFC 2518), mewakili bahawa pemprosesan akan diteruskan. |
| 200 |
Permintaan telah berjaya, respons yang diharapkan akan dikembalikan bersama respons ini. |
| 201 |
Permintaan telah dilaksanakan, dan sumber baru telah dicipta berdasarkan permintaan, dengan URI yang dikembalikan bersama header Location. Jika sumber yang diminta tidak dapat dicipta tepat pada masanya, maka '202 Accepted' harus dikembalikan. |
| 202 |
Pelayan telah menerima permintaan, tetapi belum memprosesnya. Seperti yang mungkin ditolak, permintaan akhir mungkin atau mungkin tidak dilaksanakan. Dalam kes operasi asinkron, tiada cara yang lebih mudah daripada mengembalikan kod status ini. Tujuan membalas resepon dengan kod status 202 adalah untuk membenarkan pelayan menerima permintaan proses lain (contohnya operasi berasaskan batch yang hanya dilaksanakan sekali sehari), tanpa perlu membiarkan pelanggan terus berhubung dengan pelayan sehingga operasi batch selesai. Respons yang menerima pemprosesan permintaan dan mengembalikan kod status 202 harus menyertakan beberapa maklumat yang menunjukkan keadaan pemprosesan yang sedang berlaku dalam entiti yang dikembalikan, serta penunjuk ke pemantau keadaan pemprosesan atau pengganti keadaan untuk membolehkan pengguna menilai sama ada operasi telah selesai. |
| 203 |
Pelayan telah berjaya memproses permintaan, tetapi header meta yang dikembalikan tidak mewakili set yang dikenali secara sah di pelayan asal, tetapi berasal daripada salinan tempatan atau pihak ketiga. Maklumat semasa mungkin adalah subset atau superset dari versi asal. Contohnya, metadata sumber mungkin menyebab pelayan asal mengetahui metadata yang lebih dari yang diingini. Menggunakan kod status ini adalah pilihan, dan hanya sesuai jika respons tanpa menggunakan kod status ini akan mengembalikan kod status 200 OK. |
| 204 |
Pelayan berjaya memproses permintaan, tetapi tidak perlu mengembalikan sebarang kandungan entiti, dan berharap untuk mengembalikan maklumat header yang diperbaharui. Respons mungkin mengembalikan maklumat header baru atau yang dikemaskini melalui entiti. Jika maklumat header ini ada, mereka harus sesuai dengan variabel yang diminta. Jika pelanggan adalah pelayar web, maka pelayar pengguna harus mengekalkan halaman yang telah menghantar permintaan tersebut tanpa menghasilkan sebarang perubahan pada pandangan dokumen, meskipun mengikut spesifikasi maklumat baru atau diperbaharui harus digunakan dalam pandangan aktif dokumen di pelayar pengguna. Disebabkan respons 204 dilarang mengandungi sebarang badan mesej, ia sentiasa diakhiri dengan baris kosong selepas header mesej yang pertama. |
| 205 |
Pelayan berjaya memproses permintaan dan tidak mengembalikan sebarang kandungan. Walau bagaimanapun, berbeza dengan respons 204, respons ini dengan kod status memerlukan pengirim permintaan untuk menetapkan semula pandangan dokumen. Respons ini biasanya digunakan setelah menerima input pengguna, untuk segera menetapkan semula borang, sehingga pengguna dapat dengan mudah memulakan satu lagi input. Sama seperti respons 204, respons ini juga dilarang dari mengandungi sebarang badan mesej, dan diakhiri dengan baris kosong selepas header mesej pertama. |
| 206 |
Pelayan telah berjaya memproses sebahagian permintaan GET. Alat muat turun HTTP seperti FlashGet atau Xunlei menggunakan respons ini untuk membolehkan penstriman dengan putus atau memecahkan dokumen besar kepada beberapa segmen yang dimuat turun secara serentak. Permintaan ini mesti mengandungi header Range untuk menunjukkan julat kandungan yang dikehendaki oleh pelanggan, dan mungkin mengandungi If-Range sebagai syarat permintaan. Respons mesti mengandungi domain header berikut: Content-Range untuk menunjukkan julat kandungan yang dikembalikan dalam respons ini; jika Content-Type adalah multipart/byteranges untuk muat turun berbilang segmen, setiap segmen multipart harus mengandungi domain Content-Range untuk menunjukkan julat kandungan segmen tersebut. Jika respons mengandungi Content-Length, nilainya mesti berpadanan dengan bilangan bait yang sebenarnya untuk julat kandungan 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 berbeza dengan nilai lain yang sepadan. Jika respons ini menggunakan validasi cache If-Range yang kuat, maka respons ini tidak seharusnya mengandungi header entiti lain; jika permintaan ini menggunakan validasi cache If-Range yang lemah, maka respons ini dilarang dari mengandungi header entiti lain; ini mengelakkan ketidakcocokan antara kandungan badan cache dan maklumat header entiti yang telah dikemas kini. Sebaliknya, respons ini harus mengandungi semua domain header entiti yang harus dikembalikan dalam respons 200. Jika tag ETag atau Last-Modified tidak boleh dipadankan dengan tepat, cache pelanggan dilarang untuk menggabungkan respons 206 dengan mana-mana kandungan yang sebelumnya telah disimpan dalam cache. |
| 207 |
Kod status yang diperluaskan oleh WebDAV (RFC 2518), mewakili bahawa mesej badan seterusnya akan menjadi mesej XML, dan mungkin mengandungi satu set kod respons yang berasingan berdasarkan jumlah subpermintaan yang sebelumnya. |
| 300 |
Sumber yang diminta mempunyai set respons yang boleh dipilih, setiap satu mempunyai alamat tertentu dan maklumat perdagangan yang dipandu pelayar. Pengguna atau pelayar boleh memilih alamat pilihan untuk pengalihan. Kecuali ini adalah permintaan HEAD, respons ini seharusnya mengandungi entiti yang memberikan senarai sifat sumber dan alamat, supaya pengguna atau pelayar boleh memilih alamat pengalihan yang paling sesuai. Format entiti ditentukan oleh format yang didefinisikan oleh Content-Type. Pelayar mungkin secara automatik membuat pilihan yang paling sesuai berdasarkan format respons dan keupayaan pelayar sendiri. Tentu, spesifikasi RFC 2616 tidak menetapkan bagaimana pemilihan automatik seperti ini harus dilakukan. Jika pelayan sendiri telah mempunyai pilihan respons utama, maka URI pilihan ini harus dinyatakan dalam lokasi; pelayar mungkin mengambil nilai Location ini sebagai alamat pengalihan automatik. Selain itu, kecuali ditetapkan secara tambahan, respons ini juga boleh disimpan dalam cache. |
| 301 |
Sumber yang diminta telah dipindahkan secara kekal ke lokasi baru, dan sebarang rujukan masa depan kepada sumber ini harus menggunakan salah satu daripada URI yang diberikan dalam respons ini. Jika mungkin, pelanggan yang mempunyai keupayaan untuk mengedit pautan harus secara automatik mengubah alamat permintaan kepada alamat yang dikembalikan oleh pelayan. Kecuali ditetapkan secara tambahan, respons ini juga boleh disimpan dalam cache. URI kekal baru harus dikembalikan dalam domain Location di respons. Kecuali ini adalah permintaan HEAD, maka entiti respons seharusnya mengandungi pautan ke URI yang baru dan penerangan ringkas. Jika ini bukan permintaan GET atau HEAD, pelayar dilarang secara automatik melakukan pengalihan, kecuali mendapat pengesahan pengguna, kerana keadaan permintaan mungkin telah berubah. Nota: untuk beberapa pelayar yang menggunakan protokol HTTP/1.0, apabila permintaan POST mereka menerima respons 301, permintaan pengalihan yang seterusnya akan menjadi kaedah GET. |
| 302 |
Sumber yang diminta kini memberikan respons dari URI yang berbeza dengan sementara. Oleh kerana pengalihan seperti ini bersifat sementara, pelanggan harus terus menghantar permintaan ke alamat asal untuk permintaan berikutnya. Respons ini hanya boleh disimpan dalam cache jika ditentukan dalam Cache-Control atau Expires. URI sementara yang baru harus dikembalikan dalam domain Location di respons. Kecuali ini adalah permintaan HEAD, maka entiti respons seharusnya mengandungi pautan ke lokasi baru dan penerangan ringkas. Jika ini bukan permintaan GET atau HEAD, pelayar dilarang secara automatik melakukan pengalihan, kecuali mendapat pengesahan pengguna, kerana keadaan permintaan mungkin telah berubah. Nota: walaupun spesifikasi RFC 1945 dan RFC 2068 tidak membenarkan pelanggan untuk mengubah kaedah permintaan apabila pengalihan berlaku, banyak pelayar yang ada sekarang menganggap respons 302 sebagai respons 303 dan menggunakan kaedah GET untuk mengakses URI yang ditentukan dalam Location dan mengabaikan kaedah asal permintaan. Kod status 303 dan 307 ditambahkan untuk menjelaskan tindakan yang dijangkakan oleh pelayan daripada klien. |
| 303 |
Respons untuk permintaan semasa boleh ditemui di URI lain, dan pelanggan harus menggunakan kaedah GET untuk mengakses sumber tersebut. Kaedah ini ada untuk membolehkan pengalihan hasil permintaan POST yang diaktifkan oleh skrip ke sumber baru. URI baru ini bukan pengganti rujukan sumber asal. Sementara itu, respons 303 dilarang dari disimpan dalam cache. Tentu saja, permintaan kedua (pengalihan) boleh disimpan dalam cache. URI baru harus dikembalikan dalam domain Location di respons. Kecuali ini adalah permintaan HEAD, entiti respons seharusnya mengandungi pautan ke URI baru dan penerangan ringkas. Nota: banyak pelayar sebelum versi HTTP/1.1 tidak memahami kod status 303 dengan baik. Jika perlu mempertimbangkan interaksi dengan pelayar tersebut, kod status 302 mungkin dapat memenuhi sebab kerana cara pengendalian respons 302 dengan pelayar kebanyakan sesuai dengan cara yang sama yang menghendaki pelanggan untuk mengendalikan respons 303. |
| 304 |
Jika pelanggan menghantar permintaan GET yang bersyarat dan permintaan itu dibenarkan, dan kandungan dokumen (sejak lawatan terakhir atau berdasarkan syarat permintaan) tidak berubah, maka pelayan harus mengembalikan kod status ini. Respons 304 melarang mengandungi badan mesej, oleh kerana itu sentiasa diakhiri dengan baris kosong selepas header mesej pertama. Respons ini mesti mengandungi maklumat header berikut: Tarikh, kecuali jika pelayan ini tidak mempunyai jam. Sekiranya pelayan tidak mempunyai jam tetapi masih mematuhi peraturan ini, maka pelayan proxy dan klien boleh berusaha untuk menambah medan Tarikh ke header respons yang diterima (seperti yang dinyatakan dalam RFC 2068), mekanisme cache akan berfungsi dengan baik. ETag dan/atau Content-Location jika permintaan yang sama seharusnya mengembalikan respons 200. Expires, Cache-Control, dan/atau Vary jika nilainya mungkin berbeza dengan nilai lain yang sepadan. Jika respons ini menggunakan validasi cache If-Range yang kuat, maka respons ini tidak boleh mengandungi header entiti yang lain; di lain pihak (contohnya, permintaan GET bersyarat menggunakan validasi cache If-Range yang lemah), respons ini dilarang dari mengandungi header entiti lain; ini untuk mengelakkan ketidakcocokan antara entiti cache yang dan maklumat header entiti yang telah dikemas kini. Jika kod respons 304 menunjukkan bahawa entiti tertentu tidak mempunyai cache, maka sistem cache harus mengabaikan respons ini dan menghantar semula permintaan tanpa sebarang syarat. Jika menerima respons 304 yang meminta untuk mengemas kini entri cache tertentu, maka sistem cache harus mengemas kini keseluruhan entri untuk mencerminkan semua nilai yang telah diperbaiki dalam respons. |
| 305 |
Sumber yang diminta mesti diakses melalui proksi tertentu. Maklumat mengenai URI di mana proksi tertentu terletak akan diberikan dalam domain Location, penerima perlu menghantar semula permintaan yang terpisah melalui proksi tersebut untuk mengakses sumber yang berkenaan. Hanya pelayan asal yang boleh memberikan respons 305. Nota: RFC 2068 tidak secara jelas menyatakan bahawa respons 305 adalah untuk mengalihkan permintaan yang terpisah, dan hanya boleh ditetapkan oleh pelayan asal. Mengabaikan batasan ini dapat membawa kepada akibat keselamatan yang serius. |
| 306 |
Dalam spesifikasi yang terbaru, kod status 306 tidak lagi digunakan. |
| 307 |
Sumber yang diminta kini memberikan respons dari URI yang berbeza secara sementara. Oleh kerana pengalihan seperti ini bersifat sementara, pelanggan harus terus menghantar permintaan ke alamat asal untuk permintaan berikutnya. Respons ini hanya boleh disimpan dalam cache jika ditentukan dalam Cache-Control atau Expires. URI sementara yang baru harus dikembalikan dalam domain Location di respons. Kecuali ini adalah permintaan HEAD, maka entiti respons seharusnya mengandungi pautan ke lokasi baru dan penerangan ringkas. Kerana beberapa pelayar tidak dapat mengenali respons 307, penyertaan maklumat yang perlu adalah diperlukan untuk membolehkan pengguna memahami dan membuat permintaan kepada URI baru. Jika ini bukan permintaan GET atau HEAD, pelayar dilarang secara automatik melakukan pengalihan, kecuali mendapat pengesahan pengguna, kerana keadaan permintaan mungkin telah berubah. |
| 400 |
1. Terdapat kesalahan semantik, permintaan semasa tidak dapat difahami oleh pelayan. Kecuali jika diubah, pelanggan tidak seharusnya menghantar semula permintaan ini. 2. Parameter permintaan ada kesalahan. |
| 401 |
Permintaan semasa memerlukan pengesahan pengguna. Respons ini mesti mengandungi maklumat header WWW-Authenticate yang sesuai untuk sumber yang diminta untuk meminta maklumat pengguna. Pelanggan boleh menghantar semula permintaan yang mengandungi maklumat header Authorization yang tepat. Jika permintaan semasa telah mengandungi silsilah pengesahan Authorization, semakin kod respons 401 menunjukkan bahawa pelayan telah menolak pengesahannya. Jika respons 401 mengandungi permintaan pengesahan yang sama seperti respons sebelumnya, dan pelayar telah sekurang-kurangnya cuba sekali untuk mengesahkan, pelayar harus menunjukkan maklumat entiti yang terdapat dalam respons kerana maklumat entiti ini mungkin mengandungi maklumat diagnosis yang relevan. Rujuk RFC 2617. |
| 402 |
Kod status ini rezerv untuk keperluan masa depan. |
| 403 |
Pelayan telah memahami permintaan tetapi menolak untuk mengeksekusikannya. Berbeza dengan respons 401, pengesahan tidak memberikan sebarang bantuan, dan permintaan ini tidak seharusnya dihantar semula. Jika ini bukan permintaan HEAD, dan pelayan ingin menjelaskan sebab mengapa permintaan tidak boleh dieksekusi, maka ia harus menerangkan dalam entiti. Tentu, pelayan juga boleh mengembalikan respons 404 jika ia tidak ingin memberi sebarang maklumat kepada pelanggan. |
| 404 |
Permintaan gagal, sumber yang diminta tidak dapat dijumpai di pelayan. Tiada maklumat untuk memberitahu pengguna sama ada keadaan ini adalah sementara atau kekal. Jika pelayan tahu keadaan tersebut, maka ia harus menggunakan kod status 410 untuk memberitahu bahawa sumber lama disebabkan oleh beberapa masalah konfigurasi dalaman telah kekal tidak dapat digunakan, dan tidak ada alamat jana pindahan. Kod status 404 digunakan secara meluas apabila pelayan tidak ingin mengungkapkan secara jelas mengapa permintaan ditolak atau tiada respons lain yang sesuai. |
| 405 |
Kaedah permintaan yang ditetapkan dalam baris permintaan tidak dapat digunakan untuk sumber yang diminta. Respons ini mesti mengembalikan maklumat header Allow yang menunjukkan senarai kaedah permintaan yang diterima untuk sumber semasa. Disebabkan kaedah PUT dan DELETE akan melaksanakan operasi tulis ke sumber di pelayan, kerana itu kebanyakan pelayan web tidak menyokong atau dalam konfigurasi lalai tidak membenarkan kaedah permintaan ini, mengembalikan kod kesalahan 405 untuk permintaan seperti ini secara umum. |
| 406 |
Ciri kandungan sumber yang diminta tidak memenuhi syarat dalam header permintaan, dan oleh itu tidak dapat menghasilkan entiti respons. Kecuali ini adalah permintaan HEAD, respons ini harus mengembalikan entiti yang mengandungi senarai sifat entiti dan alamat yang membolehkan pengguna atau pelayar untuk memilih entiti yang paling sesuai. Format entiti ditentukan oleh jenis media dalam header Content-Type. Pelayar boleh menggunakan format dan keupayaan sendiri untuk memilih yang terbaik. Namun, spesifikasi tidak menetapkan sebarang piawaian untuk pilihan automatik semacam itu. |
| 407 |
Mirip dengan respons 401, hanya sahaja pelanggan harus menjalankan pengesahan pada pelayan proksi. Pelayan proksi mesti mengembalikan header Proxy-Authenticate untuk meminta pengesahan. Pelanggan boleh mengembalikan maklumat header Proxy-Authorization untuk pengesahan. Rujuk RFC 2617. |
| 408 |
Permintaan telah tamat. Pelanggan tidak menyelesaikan pengiriman permintaan dalam waktu yang ditetapkan oleh pelayan. Pelanggan boleh menghantar semula permintaan ini kapan saja tanpa perubahan. |
| 409 |
Permintaan tidak dapat diselesaikan kerana konflik dengan status semasa sumber yang diminta. Kod ini hanya dibenarkan digunakan dalam situasi di mana pengguna dianggap mampu menyelesaikan konflik dan akan menghantar semula permintaan yang baru. Respons ini seharusnya mengandungi maklumat yang mencukupi agar pengguna boleh mencari punca konflik. Konflik seringkali berlaku dalam pemprosesan permintaan PUT. Contohnya, dalam suasana di mana pemeriksaan versi digunakan, maklumat versi yang dilampirkan dengan permintaan PUT untuk mengubah sumber tertentu bertentangan dengan permintaan yang sebelumnya, maka pelayan mesti mengembalikan kod kesalahan 409 untuk memberitahu bahawa permintaan tidak dapat diselesaikan. Dalam situasi ini, entiti respons kemungkinan akan menyertakan perbandingan antara dua versi yang bertentangan agar pengguna dapat menghantar semula versi baru hasil gabungan. |
| 410 |
Sumber yang diminta tidak lagi tersedia di pelayan, dan tiada alamat pengalihan yang diketahui. Keadaan ini harus dianggap kekal. Jika mungkin, pelanggan yang mempunyai keupayaan untuk menangani pautan harus, selepas mendapatkan kebenaran pengguna, menghapuskan semua rujukan ke alamat ini. Jika pelayan tidak mengetahui atau tidak dapat memastikan keadaan ini adalah kekal, maka kod status 404 harus digunakan. Kecuali ditentukan secara tambahan, respons ini boleh disimpan dalam cache. Tujuan respons 410 adalah terutamanya untuk membantu pentadbir laman web dalam menyelenggara laman web, memaklumkan kepada pengguna bahawa sumber tidak lagi tersedia, dan pemilik pelayan ingin mengeluarkan semua sambungan jauh ke sumber ini. Peristiwa ini sering berlaku dalam perkhidmatan bernilai tambah atau terhad. Begitu juga, respons 410 juga digunakan untuk memberitahu pelanggan bahawa sumber yang dimiliki oleh seorang individu tidak lagi tersedia di pelayan sedia ada. Pastikan bahawa semua sumber yang tidak lagi dapat diakses harus ditandakan sebagai '410 Gone', dan tempoh masa untuk mengekalkan pengantar yang sama adalah budi bicara pemilik pelayan. |
| 411 |
Pelayan menolak permintaan tanpa header Content-Length yang ditetapkan. Setelah menambah header Content-Length yang sah yang menunjukkan panjang isi permintaan, pelanggan boleh menghantar semula permintaan tersebut. |
| 412 |
Pelayan tidak memenuhi salah satu atau lebih syarat prasyarat yang ditentukan dalam header permintaan. Kod status ini membolehkan pelanggan menetapkan syarat prasyarat dalam metadata permintaan (data dalam header permintaan) semasa mendapatkan sumber agar kaedah permintaan tidak dapat digunakan pada sumber yang tidak dikehendaki. |
| 413 |
Pelayan menolak untuk memproses permintaan semasa kerana saiz data entiti yang dihantar melebihi had yang pelayan sanggup atau mampu untuk memproses. Dalam kes ini, pelayan boleh menutup sambungan agar pelanggan tidak terus menghantar permintaan ini. Jika keadaan ini adalah sementara, pelayan harus mengembalikan header respons Retry-After untuk memberitahu pelanggan berapa lama mereka boleh mencuba semula. |
| 414 |
Panjang URI yang diminta melebihi panjang yang boleh diterima oleh pelayan, dan oleh itu pelayan menolak untuk memberikan respons kepada permintaan ini. Ini adalah jarang berlaku, tetapi situasi umum termasuk: pengiriman borang yang seharusnya menggunakan kaedah POST menjadi kaedah GET, menyebabkan parapemintaan (Query String) yang terlalu panjang. URI pengalihan "black hole," seperti setiap pengalihan yang mengambil URI lama sebagai bahagian URI baru yang menyebabkan berulang-ulang pengalihan, menyebabkan URI terlalu panjang. Pelanggan sedang mencuba untuk mengeksploitasi kelemahan keselamatan yang terdapat pada pelayan tertentu. Pelayan seperti itu menggunakan panjang tetap untuk menyimpan atau memproses URI permintaan, dan apabila parameter selepas GET melebihi angka tertentu, ia mungkin menyebabkan kebocoran buffer yang membolehkan pelaksanaan kod yang tidak dibenarkan.[1] Pelayan tanpa kelemahan sedemikian harus mengembalikan kod status 414. |
| 415 |
Untuk kaedah permintaan semasa dan sumber yang diminta, entiti yang dihantar bukan format yang disokong oleh pelayan, oleh itu permintaan ditolak. |
| 416 |
Jika permintaan mengandungi header request Range, dan mana-mana julat yang ditentukan dalam Range tidak selari dengan julat yang terdapat pada sumber semasa, dan tidak ada header If-Range yang ditentukan dalam permintaan, maka pelayan harus mengembalikan kod status 416. Jika Range menggunakan julat bait, maka keadaan ini bermakna bahawa semua permintaan julat yang ditentukan melebihi panjang sumber semasa. Pelayan juga mesti mengandungi header Content-Range yang memberitahu panjang sumber semasa pada respons 416. Respons ini juga dilarang daripada menggunakan multipart/byteranges sebagai Content-Type. |
| 417 |
Isi yang diharapkan yang dinyatakan dalam header Expect tidak dapat dipenuhi oleh pelayan, atau pelayan ini adalah pelayan proksi yang mempunyai bukti jelas bahawa lelaran seterusnya dalam laluan yang sedang dikendalikan tidak dapat memenuhi isi Expect. |
| 421 |
Bilangan sambungan yang berada di antara alamat IP pelanggan semasa ke pelayan melebihi had maksimum yang dibenarkan oleh pelayan. Biasanya, alamat IP di sini merujuk kepada alamat pelanggan yang dilihat dari pelayan (seperti alamat gerbang pengguna atau pelayan proksi). Dalam kes ini, pengiraan bilangan sambungan mungkin melibatkan lebih daripada satu pengguna akhir. |
| 422 |
Permintaan berformat betul, tetapi kerana mengandungi kesalahan semantik, tidak dapat memberikan respons. (RFC 4918 WebDAV) 423 Locked, sumber saat ini sedang terkunci. (RFC 4918 WebDAV) |
| 424 |
Permintaan gagal kerana ralat yang berlaku dalam permintaan sebelumnya, contohnya PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Ditakrifkan dalam draf WebDav Advanced Collections, tetapi tidak muncul dalam Protokol Set Kumpulan WebDAV (RFC 3658). |
| 426 |
Pelanggan harus beralih kepada TLS/1.0. (RFC 2817) |
| 449 |
Diperluaskan oleh Microsoft, menunjukkan bahawa permintaan perlu dihantar semula setelah operasi yang sesuai dilaksanakan. |
| 500 |
Pelayan mengalami keadaan yang tidak dijangka yang membawa kepada kegagalan dalam menyelesaikan permintaan. Secara umumnya, masalah ini berlaku apabila terdapat ralat dalam kod aplikasi pelayan. |
| 501 |
Pelayan tidak menyokong salah satu fungsi yang diperlukan untuk permintaan semasa. Apabila pelayan tidak mengenali kaedah permintaan dan tidak dapat menyokong permintaan terhadap mana-mana sumber. |
| 502 |
Pelayan yang bertindak sebagai gerbang atau proksi menerima respons yang tidak sah dari pelayan hulu semasa cubaan pemprosesan permintaan. |
| 503 |
Pelayan tidak dapat memproses permintaan buat sementara disebabkan penyelenggaraan pelayan atau kelebihan beban. Keadaan ini adalah sementara dan dijangka akan pulih nanti. Jika masa kelewatan dapat dijangka, maka respons boleh mengandungi header Retry-After untuk menandakan masa kelewatan tersebut. Tanpa maklumat Retry-After, pelanggan harus berurusan dengannya seperti respons 500. Nota: kewujudan kod status 503 tidak menunjukkan bahawa pelayan harus menggunakannya apabila berada dalam keadaan overload. Beberapa pelayan hanya ingin menolak sambungan pelanggan. |
| 504 |
Pelayan yang bertindak sebagai gerbang atau proksi tidak menerima respons yang tepat waktu dari pelayan hulu (pelayan yang dikenal URI, contohnya HTTP, FTP, LDAP) atau pelayan bantuan (contohnya DNS). Nota: beberapa pelayan proksi kadang kala mengembalikan ralat 400 atau 500 ketika permintaan DNS telah tamat. |
| 505 |
Pelayan tidak menyokong, atau menolak menyokong versi HTTP yang digunakan dalam permintaan. Ini menyiratkan bahawa pelayan tidak dapat atau tidak mahu menggunakan versi yang sama dengan klien. Respons ini seharusnya mengandungi entiti yang menerangkan mengapa versi ini tidak disokong dan protokol yang disokong oleh pelayan. |
| 506 |
Diperluaskan oleh Protokol Negosiasi Kandungan yang Telus (RFC 2295) untuk menunjukkan bahawa terdapat kesalahan konfigurasi dalaman pada pelayan: sumber variabel yang diminta telah dikonfigurasi untuk menggunakan dirinya sendiri dalam negosiasi jernih, sehingga bukan tumpuan yang sesuai dalam pemprosesan pengundian. |
| 507 |
Pelayan tidak dapat menyimpan kandungan yang diperlukan untuk memenuhi permintaan. Keadaan ini dianggap sementara. WebDAV (RFC 4918) |
| 509 |
Pelayan telah mencapai had jalur. Ini bukan kod status yang rasmi, tetapi masih digunakan secara meluas. |
| 510 |
Kebijakan yang diperlukan untuk mendapatkan sumber tidak dipenuhi. (RFC 2774) |