Jadual klasifikasi kod status http yang paling lengkap dan terperinci ada di sini!

                                                                                                                                                                      

Klasifikasi kod status HTTP

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

Jadual kod status HTTP (versi 1) Jadual ini mengandungi nama Inggeris bagi kod status

410GoneSumber yang diminta oleh pelanggan tidak lagi wujud. 410 berbeza daripada 404. Jika sumber telah dipadamkan secara kekal, kod 410 boleh digunakan Pereka tapak web boleh menentukan lokasi baharu sumber melalui kod 301 411<.>412413414415416417Kod status bermula dengan 5500 501 502503504505

Senarai kod status HTTP (versi 2) Penerangan jadual ini lebih terperinci

Kod status	Kod status dalam Nama Inggeris	Penerangan bahasa Cina
Kod status bermula dengan 1
100	Teruskan	Teruskan. Pelanggan harus meneruskan permintaannya
101	Protokol Penukaran	Menukar protokol. Pelayan menukar protokol berdasarkan permintaan pelanggan. Anda hanya boleh bertukar kepada protokol yang lebih maju, contohnya, bertukar kepada versi baharu protokol HTTP
Kod status bermula dengan 2
200	OK	Permintaan berjaya. Biasanya digunakan untuk permintaan GET dan POST
201	Dibuat	telah dibuat. Berjaya meminta dan mencipta sumber baharu
202	Diterima	Diterima. Permintaan telah diterima tetapi belum diproses
203	Maklumat Bukan Berkuasa	Maklumat tidak dibenarkan. Permintaan itu berjaya. Tetapi maklumat meta yang dikembalikan bukan pada pelayan asal, tetapi salinan
204	Tiada Kandungan	Tiada kandungan. Pelayan berjaya diproses, tetapi tiada kandungan dikembalikan. Memastikan penyemak imbas terus memaparkan dokumen semasa tanpa mengemas kini halaman web
205	Tetapkan Semula Kandungan	Tetapkan semula kandungan. Pemprosesan pelayan berjaya dan terminal pengguna (cth. penyemak imbas) harus menetapkan semula paparan dokumen. Kod pemulangan ini boleh digunakan untuk mengosongkan medan borang penyemak imbas
206	Kandungan Separa	. Pelayan berjaya memproses sebahagian daripada permintaan GET
Kod status bermula dengan 3
300	Pelbagai Pilihan	Pelbagai Pilihan. Sumber yang diminta boleh termasuk berbilang lokasi, dan dengan itu senarai ciri dan alamat sumber boleh dikembalikan untuk terminal pengguna (contohnya: penyemak imbas) untuk memilih
301	Berpindah Secara Kekal	Bergerak secara kekal. Sumber yang diminta telah dialihkan secara kekal ke URI baharu, maklumat pemulangan akan termasuk URI baharu dan penyemak imbas secara automatik akan diarahkan ke URI baharu. Sebarang permintaan baharu pada masa hadapan hendaklah menggunakan URI baharu dan bukannya
302	Ditemui	Dialihkan buat sementara waktu. Sama seperti 301. Tetapi sumber itu hanya dipindahkan buat sementara waktu. Pelanggan harus terus menggunakan URI asal
303	Lihat Lain	untuk melihat alamat lain. Sama seperti 301. Gunakan permintaan GET dan POST untuk melihat
304	Tidak Diubah	Tidak diubah suai. Sumber yang diminta belum diubah suai Apabila pelayan mengembalikan kod status ini, tiada sumber akan dikembalikan. Pelanggan biasanya cache mengakses sumber dengan menyediakan pengepala yang menunjukkan bahawa pelanggan ingin memulangkan hanya sumber yang diubah suai selepas tarikh tertentu
305	Gunakan Proksi	Gunakan proksi. Sumber yang diminta mesti diakses melalui proksi
306	Tidak digunakan	Kod status HTTP usang
307	Ubah Hala Sementara	Ubah hala sementara. Sama seperti 302. Gunakan GET permintaan ubah hala
Kod status bermula dengan 4
400	Permintaan Buruk	Sintaks permintaan klien tidak betul dan pelayan tidak dapat memahaminya
401	Tidak dibenarkan	Permintaan memerlukan pengesahan pengguna
402	Pembayaran Diperlukan	Diperlukan untuk kegunaan masa hadapan
403	Dilarang	Pelayan memahami permintaan daripada pelanggan, tetapi enggan melaksanakan permintaan
404	Tidak Ditemui	Pelayan tidak dapat mencari sumber (halaman web) mengikut permintaan pelanggan. Melalui kod ini, pereka laman web boleh menyediakan halaman yang diperibadikan "Sumber yang anda minta tidak dapat ditemui"
405	Kaedah Tidak Dibenarkan	Pelanggan Kaedah dalam permintaan pelanggan adalah dilarang
406	Tidak Boleh Diterima	Pelayan tidak boleh melengkapkan permintaan berdasarkan ciri kandungan permintaan pelanggan
407	Pengesahan Proksi Diperlukan	Permintaan memerlukan pengesahan proksi, serupa dengan 401, tetapi peminta harus menggunakan proksi untuk kebenaran
408	Tamat Masa Permintaan	Pelayan menunggu terlalu lama untuk permintaan yang dihantar oleh pelanggan dan tamat masa
409	Konflik	Pelayan boleh mengembalikan kod ini apabila menyelesaikan permintaan PUT pelanggan Konflik berlaku apabila pelayan memproses permintaan
Panjang Diperlukan	Pelayan tidak boleh memproses maklumat permintaan tanpa Panjang Kandungan yang dihantar oleh pelanggan
Prasyarat Gagal	Ralat prasyarat untuk pelanggan meminta maklumat
Minta Entiti Terlalu Besar	Entiti yang diminta terlalu besar untuk diproses oleh pelayan dan oleh itu menolak bertanya. Untuk mengelakkan permintaan berterusan daripada klien, pelayan boleh menutup sambungan. Jika pelayan tidak dapat memprosesnya buat sementara waktu, ia akan mengandungi mesej balas Cuba Semula Selepas
URI Permintaan Terlalu Besar	URI Diminta Juga panjang (URI biasanya URL), pelayan tidak boleh mengendalikan
Jenis Media Tidak Disokong	Pelayan tidak boleh mengendalikan format media yang dilampirkan pada permintaan
Julat yang diminta tidak dapat memuaskan	Julat yang diminta oleh pelanggan adalah tidak sah
Jangkaan Gagal	Pelayan tidak dapat memenuhi maklumat pengepala permintaan Expect
Ralat Pelayan Dalaman	Ralat dalaman pelayan, tidak dapat melengkapkan permintaan
Tidak Dilaksanakan	Pelayan tidak menyokong fungsi yang diminta dan tidak dapat melengkapkan permintaan
Bad Gateway	Pelayan yang bertindak sebagai gateway atau proksi menerima permintaan yang tidak sah daripada pelayan jauh
Perkhidmatan Tidak Tersedia	Disebabkan terlebih beban atau beban sistem Disebabkan penyelenggaraan, pelayan tidak dapat memproses permintaan pelanggan buat sementara waktu. Tempoh kelewatan boleh disertakan dalam maklumat pengepala Cuba Semula Selepas pelayan
Tamat Masa Gerbang	Pelayan bertindak sebagai get laluan atau proksi , permintaan itu tidak diperolehi daripada pelayan jauh dalam masa
Versi HTTP tidak disokong	Pelayan tidak menyokong yang diminta Versi protokol HTTP dan tidak dapat diselesaikan

Kod status	Maksud
100	Pelanggan harus terus menghantar permintaan. Respons sementara ini digunakan untuk memaklumkan klien bahawa sebahagian permintaannya telah diterima oleh pelayan dan masih belum ditolak. Pelanggan HARUS terus menghantar baki permintaan, atau abaikan respons ini jika permintaan telah selesai. Pelayan mesti menghantar respons akhir kepada klien selepas permintaan selesai.
101	Pelayan telah memahami permintaan pelanggan dan akan memberitahu pelanggan melalui pengepala mesej Naik Taraf untuk menggunakan protokol lain untuk melengkapkan permintaan. Selepas menghantar baris kosong terakhir respons ini, pelayan akan bertukar kepada protokol yang ditakrifkan dalam pengepala Naik Taraf. Langkah-langkah yang sama hanya perlu diambil apabila lebih berfaedah untuk beralih kepada protokol baharu. Sebagai contoh, terdapat kelebihan untuk menukar kepada versi HTTP baharu berbanding versi yang lebih lama, atau bertukar kepada protokol masa nyata dan segerak untuk menyampaikan sumber yang memanfaatkan ciri tersebut.
102	Kod status yang dilanjutkan oleh WebDAV (RFC 2518), menunjukkan bahawa pemprosesan akan diteruskan.
200	Permintaan telah berjaya dan pengepala respons atau badan data yang dijangkakan oleh permintaan akan dikembalikan dengan respons ini.
201	Permintaan telah dilaksanakan dan sumber baharu telah dibuat berdasarkan keperluan permintaan dan URInya telah dikembalikan dengan maklumat pengepala Lokasi. Jika sumber yang diperlukan tidak dapat dibuat dalam masa, '202 Diterima' harus dikembalikan.
202	Permintaan telah diterima oleh pelayan tetapi belum diproses lagi. Sama seperti ia mungkin dinafikan, permintaan itu mungkin atau mungkin tidak akhirnya dilaksanakan. Dalam kes operasi tak segerak, tiada cara yang lebih mudah daripada menghantar kod status ini. Tujuan mengembalikan respons kod status 202 adalah untuk membenarkan pelayan menerima permintaan daripada proses lain (seperti operasi berasaskan kelompok yang hanya dilakukan sekali sehari) tanpa perlu memastikan klien disambungkan ke pelayan sehingga operasi kelompok selesai. Respons yang menerima pemprosesan permintaan dan mengembalikan kod status 202 harus mengandungi beberapa maklumat dalam entiti yang dikembalikan yang menunjukkan status semasa pemprosesan, serta penunjuk kepada pemantau status pemprosesan atau ramalan status supaya pengguna boleh menganggarkan sama ada operasi telah selesai.
203	Pelayan telah berjaya memproses permintaan, tetapi maklumat meta pengepala entiti yang dikembalikan bukanlah set ditentukan yang sah pada pelayan asal, tetapi datang daripada tempatan atau pihak ketiga Salinan pihak ketiga. Maklumat semasa mungkin subset atau superset versi asal. Contohnya, mengandungi metadata untuk sumber boleh menyebabkan pelayan asal mengetahui maklumat super tentang metadata tersebut. Menggunakan kod status ini tidak diperlukan dan hanya sesuai jika respons akan mengembalikan 200 OK tanpa kod status ini.
204	Pelayan berjaya memproses permintaan, tetapi tidak perlu memulangkan sebarang kandungan entiti dan mahu mengembalikan maklumat meta yang dikemas kini. Respons mungkin mengembalikan metamaklumat baharu atau dikemas kini dalam bentuk pengepala entiti. Pengepala ini, jika ada, harus sepadan dengan pembolehubah yang diminta. Jika klien ialah penyemak imbas, penyemak imbas pengguna HARUS mengekalkan halaman yang permintaannya dibuat tanpa sebarang perubahan pada paparan dokumen, walaupun jika metamaklumat baharu atau dikemas kini harus digunakan pada aktiviti penyemak imbas pengguna mengikut spesifikasi Dokumen yang dilihat. Memandangkan respons 204 dilarang daripada mengandungi sebarang badan mesej, ia sentiasa berakhir dengan baris kosong pertama selepas pengepala mesej.
205	Pelayan berjaya memproses permintaan dan tidak mengembalikan apa-apa. Tetapi tidak seperti respons 204, respons yang mengembalikan kod status ini memerlukan peminta untuk menetapkan semula paparan dokumen. Respons ini digunakan terutamanya untuk menetapkan semula borang serta-merta selepas menerima input pengguna supaya pengguna boleh memulakan input lain dengan mudah. Seperti respons 204, respons ini dilarang daripada mengandungi sebarang badan mesej dan berakhir dengan baris kosong pertama selepas pengepala mesej.
206	Pelayan telah berjaya memproses sebahagian daripada permintaan GET. Alat muat turun HTTP seperti FlashGet atau Thunder menggunakan jenis respons ini untuk menyambung semula muat turun yang terganggu atau memecahkan dokumen besar kepada berbilang segmen muat turun untuk muat turun serentak. Permintaan mesti menyertakan pengepala Julat untuk menunjukkan julat kandungan yang ingin diperolehi oleh klien, dan mungkin memasukkan Julat-Jika sebagai syarat permintaan. Respons mesti mengandungi medan pengepala berikut: Julat Kandungan digunakan untuk menunjukkan julat kandungan yang dikembalikan dalam respons ini jika muat turun berbilang bahagian dengan berbilang bahagian/bait Jenis Kandungan, setiap bahagian berbilang bahagian harus mengandungi Julat Kandungan; domain digunakan untuk menunjukkan skop kandungan perenggan ini. Jika Panjang Kandungan disertakan dalam respons, nilainya mesti sepadan dengan bilangan bait sebenar dalam julat kandungan yang dikembalikannya. Tarikh ETag dan/atau Lokasi Kandungan, jika permintaan yang sama sepatutnya telah mengembalikan 200 respons. Tamat tempoh, Kawalan Cache dan/atau Berubah-ubah, jika nilainya mungkin berbeza daripada nilai yang sepadan dengan respons sebelumnya yang lain kepada pembolehubah yang sama.Jika permintaan respons ini menggunakan pengesahan cache kuat Julat-Jika, maka respons ini tidak seharusnya mengandungi pengepala entiti lain jika permintaan respons ini menggunakan pengesahan cache lemah Julat-Jika, maka respons ini dilarang daripada mengandungi pengepala entiti lain; kandungan entiti yang dicache dan maklumat pengepala entiti yang dikemas kini. Jika tidak, respons ini harus mengandungi semua medan pengepala entiti yang harus dikembalikan dalam respons 200. Jika pengepala ETag atau Last-Modified tidak sepadan dengan tepat, cache klien tidak seharusnya menggabungkan kandungan yang dikembalikan oleh respons 206 dengan mana-mana kandungan yang dicache sebelum ini. Sebarang cache yang tidak menyokong pengepala Julat dan Julat Kandungan dilarang daripada menyimpan cache kandungan yang dikembalikan oleh respons 206.
207	Kod status yang dilanjutkan oleh WebDAV (RFC 2518), menunjukkan bahawa isi mesej seterusnya akan menjadi mesej XML dan mungkin berbeza mengikut bilangan sub-permintaan sebelumnya , yang mengandungi satu siri kod respons bebas.
300	Sumber yang diminta mempunyai satu siri respons pilihan, masing-masing dengan alamat khusus dan maklumat rundingan pemandu penyemak imbas. Pengguna atau penyemak imbas boleh memilih alamat pilihan untuk ubah hala. Melainkan ini adalah permintaan HEAD, respons harus termasuk entiti dengan senarai atribut sumber dan alamat yang pengguna atau penyemak imbas boleh memilih alamat ubah hala yang paling sesuai. Format entiti ini ditentukan oleh format yang ditakrifkan oleh Jenis Kandungan. Penyemak imbas secara automatik boleh membuat pilihan yang paling sesuai berdasarkan format respons dan keupayaan pelayar itu sendiri. Sudah tentu, spesifikasi RFC 2616 tidak menyatakan cara pemilihan automatik sedemikian harus dilakukan. Jika pelayan itu sendiri sudah mempunyai pilihan maklum balas pilihan, URI maklum balas ini harus dinyatakan dalam Lokasi penyemak imbas boleh menggunakan nilai Lokasi ini sebagai alamat untuk ubah hala automatik. Selain itu, respons ini boleh disimpan dalam cache melainkan dinyatakan sebaliknya.
301	Sumber yang diminta telah dialihkan secara kekal ke lokasi baharu dan sebarang rujukan masa hadapan kepada sumber ini hendaklah menggunakan salah satu daripada beberapa URI yang dikembalikan dengan respons ini . Jika boleh, pelanggan yang mempunyai keupayaan menyunting pautan harus mengubah suai alamat yang diminta secara automatik kepada alamat yang dikembalikan daripada pelayan. Melainkan dinyatakan sebaliknya, respons ini juga boleh dicache. URI berterusan baharu harus dikembalikan dalam medan Lokasi respons. Melainkan ini adalah permintaan HEAD, entiti respons harus mengandungi hiperpautan ke URI baharu dan penerangan ringkas. Jika ini bukan permintaan GET atau HEAD, penyemak imbas melarang ubah hala automatik melainkan disahkan oleh pengguna, kerana syarat permintaan mungkin berubah dengan sewajarnya. Nota: Untuk sesetengah penyemak imbas yang menggunakan protokol HTTP/1.0, apabila permintaan POST yang mereka hantar menerima respons 301, permintaan ubah hala seterusnya akan menjadi kaedah GET.
302	Sumber yang diminta kini bertindak balas sementara kepada permintaan daripada URI yang berbeza. Oleh kerana ubah hala tersebut bersifat sementara, pelanggan harus terus menghantar permintaan masa hadapan ke alamat asal. Respons ini boleh disimpan dalam cache hanya jika dinyatakan dalam Cache-Control atau Expires. URI sementara baharu harus dikembalikan dalam medan Lokasi respons. Melainkan ini adalah permintaan HEAD, entiti respons harus mengandungi hiperpautan ke URI baharu dan penerangan ringkas. Jika ini bukan permintaan GET atau HEAD, penyemak imbas melarang ubah hala automatik melainkan disahkan oleh pengguna, kerana syarat permintaan mungkin berubah dengan sewajarnya. Nota: Walaupun spesifikasi RFC 1945 dan RFC 2068 tidak membenarkan pelanggan menukar kaedah permintaan semasa mengubah hala, banyak penyemak imbas sedia ada menganggap respons 302 sebagai respons 303 dan menggunakan kaedah GET untuk mengakses URI yang ditentukan dalam Lokasi, tanpa mengira daripada Kaedah permintaan asal. Kod status 303 dan 307 telah ditambahkan untuk menjelaskan tindak balas yang pelayan harapkan daripada klien.
303	Respons yang sepadan dengan permintaan semasa boleh didapati di URI lain dan pelanggan harus menggunakan GET untuk mengakses sumber tersebut. Kaedah ini wujud terutamanya untuk membenarkan output permintaan POST yang diaktifkan skrip diubah hala ke sumber baharu. URI baharu ini bukan rujukan gantian kepada sumber asal. Pada masa yang sama, 303 respons dilarang daripada dicache. Sudah tentu, permintaan kedua (lencong) mungkin dicache. URI baharu harus dikembalikan dalam medan Lokasi respons. Melainkan ini adalah permintaan HEAD, entiti respons harus mengandungi hiperpautan ke URI baharu dan penerangan ringkas. NOTA: Banyak pelayar pra-HTTP/1.1 tidak memahami status 303 dengan betul. Jika anda perlu mempertimbangkan interaksi dengan penyemak imbas ini, kod status 302 sepatutnya mencukupi, kerana kebanyakan penyemak imbas mengendalikan 302 respons dengan tepat seperti spesifikasi di atas memerlukan pelanggan mengendalikan 303 respons.
304	Jika pelanggan menghantar permintaan GET bersyarat dan permintaan itu dibenarkan, dan kandungan dokumen (sama ada sejak akses terakhir atau berdasarkan permintaan keadaan) tidak berubah, pelayan harus mengembalikan kod status ini. Respons 304 dilarang daripada memasukkan badan mesej, jadi ia sentiasa berakhir dengan baris kosong pertama selepas pengepala mesej.Respons MESTI mengandungi maklumat pengepala berikut: Tarikh, melainkan pelayan tidak mempunyai jam. Jika pelayan tanpa jam mengikut peraturan ini, maka pelayan proksi dan pelanggan boleh menambah medan Tarikh untuk menerima pengepala respons sendiri (seperti yang dinyatakan dalam RFC 2068), dan mekanisme caching akan berfungsi seperti biasa. ETag dan/atau Lokasi Kandungan, jika permintaan yang sama sepatutnya telah mengembalikan 200 respons. Tamat tempoh, Kawalan Cache dan/atau Berubah-ubah, jika nilainya mungkin berbeza daripada nilai yang sepadan dengan respons sebelumnya yang lain kepada pembolehubah yang sama. Jika permintaan respons ini menggunakan pengesahan cache yang kuat, maka respons ini tidak seharusnya mengandungi pengepala entiti lain (contohnya, permintaan GET bersyarat menggunakan pengesahan cache yang lemah), respons ini dilarang daripada mengandungi pengepala entiti lain; kandungan entiti dan maklumat pengepala entiti yang dikemas kini. Jika respons 304 menunjukkan bahawa entiti tidak dicache pada masa ini, sistem caching mesti mengabaikan respons dan mengulangi permintaan tanpa sekatan. Jika respons 304 diterima yang memerlukan kemas kini kepada entri cache, sistem cache mesti mengemas kini keseluruhan entri untuk mencerminkan nilai semua medan yang dikemas kini dalam respons.
305	Sumber yang diminta mesti diakses melalui proksi yang ditentukan. Medan Lokasi akan memberikan maklumat URI di mana proksi yang ditentukan terletak Penerima perlu berulang kali menghantar permintaan berasingan untuk mengakses sumber yang sepadan melalui proksi ini. Hanya pelayan asal boleh mewujudkan respons 305. Nota: RFC 2068 tidak menyatakan bahawa respons 305 bertujuan untuk mengubah hala permintaan tunggal dan hanya boleh diwujudkan oleh pelayan asal. Mengabaikan sekatan ini boleh membawa kepada akibat keselamatan yang serius.
306	Dalam versi spesifikasi terkini, kod status 306 tidak lagi digunakan.
307	Sumber yang diminta kini bertindak balas sementara kepada permintaan daripada URI yang berbeza. Oleh kerana ubah hala tersebut bersifat sementara, pelanggan harus terus menghantar permintaan masa hadapan ke alamat asal. Respons ini boleh disimpan dalam cache hanya jika dinyatakan dalam Cache-Control atau Expires. URI sementara baharu harus dikembalikan dalam medan Lokasi respons. Melainkan ini adalah permintaan HEAD, entiti respons harus mengandungi hiperpautan ke URI baharu dan penerangan ringkas. Oleh kerana sesetengah penyemak imbas tidak mengenali respons 307, maklumat yang diperlukan di atas perlu ditambah supaya pengguna boleh memahami dan membuat permintaan akses kepada URI baharu. Jika ini bukan permintaan GET atau HEAD, penyemak imbas melarang ubah hala automatik melainkan disahkan oleh pengguna, kerana syarat permintaan mungkin berubah dengan sewajarnya.
400	1. Semantik tidak betul dan permintaan semasa tidak dapat difahami oleh pelayan. Pelanggan tidak seharusnya menyerahkan semula permintaan ini melainkan diubah suai. 2. Parameter permintaan tidak betul.
401	Permintaan semasa memerlukan pengesahan pengguna. Respons MESTI termasuk pengepala WWW-Authenticate yang sesuai dengan sumber yang diminta yang meminta maklumat pengguna. Pelanggan boleh berulang kali menyerahkan permintaan yang mengandungi pengepala Kebenaran yang sesuai. Jika permintaan semasa sudah termasuk sijil Kebenaran, respons 401 menunjukkan bahawa pengesahan pelayan telah menolak sijil tersebut. Jika respons 401 mengandungi pertanyaan pengesahan yang sama seperti respons sebelumnya dan penyemak imbas telah mencuba pengesahan sekurang-kurangnya sekali, penyemak imbas harus memaparkan maklumat entiti yang terkandung dalam respons kepada pengguna, kerana maklumat entiti ini mungkin mengandungi maklumat diagnostik yang berkaitan . Lihat RFC 2617.
402	Kod status ini dikhaskan untuk keperluan masa hadapan yang mungkin.
403	Pelayan memahami permintaan itu, tetapi enggan melaksanakannya. Tidak seperti respons 401, pengesahan tidak memberikan sebarang bantuan dan permintaan itu tidak boleh diserahkan semula. Jika ini bukan permintaan HEAD dan pelayan ingin dapat menjelaskan mengapa permintaan itu tidak dapat dilaksanakan, maka sebab penolakan harus diterangkan dalam entiti. Sudah tentu, pelayan juga boleh mengembalikan respons 404 jika ia tidak mahu klien mendapatkan sebarang maklumat.
404	Permintaan gagal sumber yang diminta tidak ditemui pada pelayan. Tiada maklumat untuk memberitahu pengguna sama ada keadaan itu sementara atau kekal. Jika pelayan mengetahui situasi itu, ia harus menggunakan kod status 410 untuk memaklumkan bahawa sumber lama tidak tersedia secara kekal kerana beberapa masalah mekanisme konfigurasi dalaman dan tiada alamat lompat. Kod status 404 digunakan secara meluas apabila pelayan tidak mahu mendedahkan mengapa permintaan itu ditolak atau tiada respons lain yang sesuai tersedia.
405	Kaedah permintaan yang dinyatakan dalam baris permintaan tidak boleh digunakan untuk meminta sumber yang sepadan. Respons mesti mengembalikan maklumat pengepala Benarkan untuk menunjukkan senarai kaedah permintaan yang boleh diterima oleh sumber semasa. Memandangkan kaedah PUT dan DELETE akan menulis sumber pada pelayan, kebanyakan pelayan web tidak menyokong atau tidak membenarkan kaedah permintaan di atas di bawah konfigurasi lalai, dan ralat 405 akan dikembalikan untuk permintaan tersebut.
406	Ciri kandungan sumber yang diminta tidak dapat memenuhi syarat dalam pengepala permintaan, jadi entiti respons tidak boleh dijana. Melainkan ini adalah permintaan HEAD, respons harus mengembalikan entiti yang mengandungi senarai atribut dan alamat entiti yang pengguna atau penyemak imbas boleh memilih yang paling sesuai. Format entiti ditentukan oleh jenis media yang ditakrifkan dalam pengepala Jenis Kandungan. Penyemak imbas boleh membuat pilihan terbaiknya sendiri berdasarkan format dan keupayaannya. Walau bagaimanapun, spesifikasi tidak mentakrifkan sebarang kriteria untuk membuat pemilihan automatik tersebut.
407	Serupa dengan respons 401, kecuali pelanggan mesti mengesahkan dengan pelayan proksi. Pelayan proksi mesti mengembalikan Proxy-Authenticate untuk pertanyaan identiti. Pelanggan boleh mengembalikan pengepala Kebenaran Proksi untuk pengesahan. Lihat RFC 2617.
408	Minta tamat masa. Pelanggan tidak menyelesaikan penghantaran permintaan dalam masa pelayan bersedia untuk menunggu. Pelanggan boleh menghantar semula permintaan ini pada bila-bila masa tanpa membuat sebarang perubahan.
409	Permintaan tidak dapat diselesaikan kerana konflik dengan keadaan semasa sumber yang diminta. Kod ini hanya boleh digunakan jika pengguna dipercayai dapat menyelesaikan konflik dan menyerahkan semula permintaan baharu. Respons harus mengandungi maklumat yang mencukupi untuk pengguna menemui sumber konflik. Konflik biasanya berlaku dalam pemprosesan permintaan PUT. Contohnya, dalam persekitaran yang menggunakan semakan versi, jika maklumat versi yang dilampirkan pada permintaan pengubahsuaian untuk sumber tertentu yang diserahkan oleh PUT bercanggah dengan permintaan sebelumnya (pihak ketiga), maka pelayan harus mengembalikan ralat 409 pada masa ini. Maklumkan kepada pengguna bahawa permintaan tidak dapat diselesaikan. Pada masa ini, entiti respons berkemungkinan mengandungi perbandingan perbezaan antara dua versi yang bercanggah, supaya pengguna boleh menyerahkan semula versi baharu selepas digabungkan.
410	Sumber yang diminta tidak lagi tersedia pada pelayan dan tidak mempunyai alamat pemajuan yang diketahui. Situasi sedemikian harus dianggap kekal. Jika boleh, pelanggan yang mempunyai keupayaan menyunting pautan harus mengalih keluar semua rujukan ke alamat ini dengan kebenaran pengguna. Jika pelayan tidak tahu atau tidak dapat menentukan sama ada keadaan itu kekal, maka kod status 404 harus digunakan. Melainkan dinyatakan sebaliknya, respons ini boleh disimpan dalam cache. Tujuan respons 410 adalah terutamanya untuk membantu pentadbir tapak web menyelenggara tapak web, memberitahu pengguna bahawa sumber itu tidak lagi tersedia, dan pemilik pelayan berharap semua sambungan jauh yang menghala ke sumber ini juga akan dipadamkan. Jenis kejadian ini adalah perkara biasa dalam masa terhad, perkhidmatan nilai tambah. Begitu juga, respons 410 juga digunakan untuk memberitahu klien bahawa sumber yang asalnya milik individu tidak lagi tersedia di tapak pelayan semasa. Sudah tentu, terpulang sepenuhnya kepada pemilik pelayan sama ada semua sumber yang tidak tersedia secara kekal perlu ditandakan sebagai '410 Gone' dan berapa lama mereka perlu mengekalkan tanda ini.
411	Pelayan enggan menerima permintaan tanpa pengepala Panjang Kandungan ditentukan. Selepas menambah pengepala Panjang Kandungan yang sah yang menunjukkan panjang badan mesej permintaan, pelanggan boleh menyerahkan permintaan itu semula.
412	Pelayan gagal memenuhi satu atau lebih prasyarat yang diberikan dalam medan pengepala permintaan. Kod status ini membolehkan pelanggan menetapkan prasyarat dalam metamaklumat permintaan (data medan pengepala permintaan) apabila mendapatkan semula sumber, dengan itu menghalang kaedah permintaan daripada digunakan pada sumber selain daripada yang diharapkan.
413	Pelayan enggan memproses permintaan semasa kerana saiz data entiti yang diserahkan oleh permintaan melebihi julat yang pelayan sanggup atau mampu kendalikan . Dalam kes ini, pelayan boleh menutup sambungan untuk menghalang pelanggan daripada terus menghantar permintaan ini. Jika keadaan adalah sementara, pelayan harus mengembalikan pengepala respons Cuba Semula Selepas untuk memaklumkan pelanggan berapa lama ia boleh menunggu untuk mencuba lagi.
414	URI yang diminta adalah lebih panjang daripada yang boleh ditafsirkan oleh pelayan, jadi pelayan enggan melayan permintaan tersebut. Ini agak jarang berlaku termasuk: Penyerahan borang yang sepatutnya menggunakan kaedah POST menjadi kaedah GET, menyebabkan rentetan pertanyaan menjadi terlalu panjang. Ubah hala URI "lubang hitam", contohnya, setiap ubah hala menggunakan URI lama sebagai sebahagian daripada URI baharu, menghasilkan URI yang terlalu lama selepas beberapa ubah hala. Pelanggan cuba mengeksploitasi lubang keselamatan dalam beberapa pelayan untuk menyerang pelayan. Pelayan jenis ini menggunakan penimbal panjang tetap untuk membaca atau mengendalikan URI yang diminta Apabila parameter selepas GET melebihi nilai tertentu, limpahan penimbal mungkin berlaku, menyebabkan kod sewenang-wenangnya dilaksanakan [1]. Pelayan tanpa kelemahan sedemikian harus mengembalikan kod status 414.
415	Untuk kaedah semasa yang diminta dan sumber yang diminta, entiti yang diserahkan dalam permintaan itu bukan dalam format yang disokong oleh pelayan, jadi permintaan itu ditolak.
416	Jika permintaan mengandungi pengepala permintaan Julat, dan sebarang julat data yang dinyatakan dalam Julat tidak bertepatan dengan julat sumber semasa yang tersedia dan permintaan mengandungi Jika pengepala permintaan Julat-Jika tidak ditakrifkan, pelayan harus mengembalikan kod status 416.Jika Julat menggunakan julat bait, maka keadaan ini bermakna kedudukan bait pertama semua julat data yang ditentukan oleh permintaan melebihi panjang sumber semasa. Pelayan juga harus memasukkan pengepala entiti Julat Kandungan untuk menunjukkan panjang sumber semasa sambil mengembalikan kod status 416. Respons ini juga dilarang daripada menggunakan berbilang bahagian/bait sebagai Jenis Kandungannya.
417	Kandungan yang dijangkakan yang dinyatakan dalam pengepala permintaan Expect tidak dapat dipenuhi oleh pelayan, atau pelayan ialah pelayan proksi dan ia mempunyai bukti yang jelas bahawa ia adalah tidak digunakan dalam laluan semasa Pada nod seterusnya, kandungan Expect tidak boleh dipenuhi.
421	Bilangan sambungan ke pelayan daripada alamat IP klien semasa melebihi julat maksimum pelayan yang dibenarkan. Biasanya, alamat IP di sini merujuk kepada alamat klien yang dilihat dari pelayan (seperti gerbang masuk pengguna atau alamat pelayan proksi). Dalam kes ini, kiraan sambungan mungkin melibatkan lebih daripada satu pengguna akhir.
422	Bilangan sambungan ke pelayan daripada alamat IP klien semasa melebihi julat maksimum pelayan yang dibenarkan. Biasanya, alamat IP di sini merujuk kepada alamat klien yang dilihat dari pelayan (seperti gerbang masuk pengguna atau alamat pelayan proksi). Dalam kes ini, kiraan sambungan mungkin melibatkan lebih daripada satu pengguna akhir.
422	Format permintaan adalah betul, tetapi tidak boleh bertindak balas kerana ralat semantik. (RFC 4918 WebDAV) 423 Dikunci Sumber semasa dikunci. (RFC 4918 WebDAV)
424	Permintaan semasa gagal kerana ralat yang berlaku dalam permintaan sebelumnya, seperti PROPPATCH. (RFC 4918 WebDAV)
425	ditakrifkan dalam draf Koleksi Lanjutan WebDav, tetapi tidak muncul dalam Protokol Koleksi Jujukan WebDAV (RFC 3658).
426	Pelanggan harus bertukar kepada TLS/1.0. (RFC 2817)
449	Dilanjutkan oleh Microsoft, menunjukkan bahawa permintaan harus dicuba semula selepas melakukan tindakan yang sesuai.
500	Pelayan menghadapi keadaan yang tidak dijangka yang menghalangnya daripada melengkapkan pemprosesan permintaan. Secara umumnya, masalah ini akan berlaku apabila terdapat ralat dalam kod program pelayan.
501	Pelayan tidak menyokong ciri yang diperlukan oleh permintaan semasa. Apabila pelayan tidak mengenali kaedah yang diminta dan tidak dapat menyokong permintaannya untuk sebarang sumber.
502	Pelayan yang berfungsi sebagai get laluan atau proksi menerima respons tidak sah daripada pelayan huluan apabila cuba melaksanakan permintaan.
503	Disebabkan penyelenggaraan pelayan sementara atau lebihan beban, pelayan tidak dapat memproses permintaan pada masa ini. Keadaan ini bersifat sementara dan akan dipulihkan selepas satu tempoh masa. Jika kelewatan boleh dijangkakan, respons boleh termasuk pengepala Cuba Semula Selepas untuk menunjukkan kelewatan. Jika mesej Retry-After ini tidak diberikan, pelanggan HARUS mengendalikannya dengan cara yang sama ia mengendalikan respons 500. Nota: Kewujudan kod status 503 tidak bermakna pelayan mesti menggunakannya apabila ia terlebih muatan. Sesetengah pelayan hanya ingin menafikan sambungan daripada pelanggan.
504	Apabila pelayan berfungsi sebagai get laluan atau proksi cuba untuk melaksanakan permintaan, ia gagal mendapatkan permintaan dalam masa daripada pelayan huluan (pelayan dikenal pasti oleh URI, seperti HTTP, FTP, LDAP ) atau pelayan kedua (mis. DNS) menerima respons. Nota: Sesetengah pelayan proksi akan mengembalikan ralat 400 atau 500 apabila pertanyaan DNS tamat masa
505	Pelayan tidak menyokong, atau enggan menyokong, HTTP versi yang digunakan dalam permintaan . Ini menunjukkan bahawa pelayan tidak dapat atau tidak mahu menggunakan versi yang sama seperti klien. Respons harus mengandungi entiti yang menerangkan sebab versi tidak disokong dan protokol yang disokong oleh pelayan.
506	dilanjutkan oleh Protokol Rundingan Kandungan Telus (RFC 2295) dan mewakili ralat konfigurasi pelayan dalaman: sumber hujah rundingan yang diminta dikonfigurasikan untuk berada dalam Uses sendiri dalam perundingan kandungan yang telus dan oleh itu bukan fokus yang sesuai dalam proses perundingan.
507	Pelayan tidak boleh menyimpan kandungan yang diperlukan untuk melengkapkan permintaan. Keadaan ini dianggap sementara. WebDAV (RFC 4918)
509	Pelayan telah mencapai had lebar jalurnya. Ini bukan kod status rasmi, tetapi masih digunakan secara meluas.
510	Strategi yang diperlukan untuk mendapatkan sumber tidak dipenuhi. (RFC 2774)

Pembelajaran yang disyorkan: "Tutorial Video PHP" 

Atas ialah kandungan terperinci Jadual klasifikasi kod status http yang paling lengkap dan terperinci ada di sini!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!