في كل مرة يتم فيها تشغيل مهمة على جهاز مراقب، يقوم الخادم المستهدف بإرجاع رموز حالة HTTP للإشارة إلى حالة الاستجابة من الخادم.
ستظهر رموز حالة HTTP هذه، أو رموز أخطاء الشبكة، في نتائج جلسة المراقبة وكذلك في إعلامات التنبيه. يتم الاحتفاظ برموز الحالة هذه من قبل هيئة الأرقام المخصصة للإنترنت (IANA) ويمكن العثور على أحدث قائمة بالرموز هنا.
باستخدام الفلاتر، يمكنك إزالة النتائج التي تحتوي على رموز حالة محددة من مهامك وتنبيهاتك وتقاريرك. انقر على المستندات المرجعية RFC في القائمة أدناه للحصول على التفاصيل الكاملة لرموز الحالة.
Wh
a
t هو بروتوكول HTTP
؟
في كل مرة يزور فيها المستخدم موقعا على الويب ، فإنه يقدم طلبا من متصفحه / عميله إلى خادم يستجيب للموارد التي طلبها. تتبع جميع هذه الطلبات معيار HTTP (بروتوكول نقل النص التشعبي). The HTTP البروتوكول ، الذي يعد من الناحية الفنية جزءا من طبقة التطبيق داخل مجموعة بروتوكول الإنترنت ، هو واحد فقط العديد من البروتوكولاتتحت جناح IP. ال بروتوكول HTTP هو العمود الفقري للإنترنت المستخدم للاتصال وإرسال البيانات بين العملاء والخوادم. بعض بروتوكولات الإنترنت الأخرى الأكثر شيوعا لقد صادف الكثيرون ما يلي:
بروتوكولات طبقة التطبيق
ال تطبيق لاtايه يحدد البروتوكولات وطرق الواجهة المستخدمة من قبل العملاء والخوادم. ومن هل الطبقة ثهنا يحدث التفاعل بين الشخص والكمبيوتر أد – معلومات يمكن إرسالها ذهابا وإيابا من خادم عبر عميل / متصفح وتفسيرها وعرضها للمستخدمين.
- DNS
:
يقوم بروتوكول DNS (نظام أسماء النطاقات) بتحويل أسماء النطاقات إلى عناوين IP قابلة للقراءة البشرية للمتصفح بحيث يمكن تحميل الموارد.
FTP
: يستخدم بروتوكول FTP (بروتوكول نقل الملفات) لنقل الملفات بين المستعرض والخادم معشبكة الكمبيوتر.- SMTP
: يستخدم بروتوكول SMTP (بروتوكول نقل البريد البسيط) لإرسال رسائل بريد إلكتروني بين المرسلين والمستقبلين على الشبكة.
- TLS /
SSL: تم إهمال بروتوكول SSL (طبقة مآخذ التوصيل الآمنة) رسميا في 201
5. تم تقديم TLS (أمان طبقة النقل) بدلا منه لتوفير طريقة آمنة للتواصل عبر الشبكة.
IMAP
: يتم استخدام بروتوكول IMAP (بروتوكول الوصول إلى الرسائل عبر الإنترنت) من أجل إدارة الرسائل وتلقيها من خادم بريد إلكتروني. على عكس SMTP، لا يمكنك استخدام بروتوكول IMAP لإرسال رسائل البريد الإلكتروني.
POP
: بروتوكول POP (بروتوكول مكتب البريد) يشبه IMAP ، ولكن الفرق هو أن بروتوكول POP يسمح للمستخدم بتلقي رسائل من خادم بريد إلكتروني ، ولكن يتم حذف الرسالة بعد ذلك من خادم البريد الإلكتروني. يمكن لبروتوكول IMAP مزامنة الرسائل عبر أجهزة متعددة. يعتمد ذلك حقا على الطريقة التي تريد أن يصل بها المستخدمون إلى رسائل البريد الإلكتروني الخاصة بهم.- SIP
: بروتوكول SIP (بروتوكول بدء الجلسة) هو بروتوكول إشارة يستخدم في الصوت في الوقت الفعلي ، تطبيقات الفيديو والمراسلة. SIP هو البروتوكول الذي يستخدم لتمكين وديحيلة VoIP (Voice عبر بروتوكول الإنترنت) خدمات. رشف يستخدم أيضا بالاقتران مع بروتوكولات أخرى، مثل SDP (بروتوكول وصف الجلسة) وUDP وTCP وTLS لنقل بيانات الجلسة والوسائط.
بروتوكولات طبقة النقل
تتعامل طبقة النقل مع نقل البيانات ، والتي تتضمن أيضا TCP و UDP البروتوكولات، وضمان إرسال البيانات واستقبالها بشكل صحيح وفوري.
- TCP: يتم استخدام بروتوكول TCP (بروتوكول التحكم في النقل) لضمان أمان عمليات الإرسال بين العميل والخادم وأن تمت معالجة الاتصال بالكامل. على سبيل المثال متى يرسل الخادم ملفا مرة أخرى بسبب طلب عميل ، وستتواصل طبقة HTTP مع طبقة النقل لإعداد وإرسال الملف المطلوب. بروتوكول TCP يدير عملية التجميع والإرسال (وأحيانا إعادة الإرسال، إذا لزم الأمر) حزم البيانات ويضمن ذلك تم إرسال جميع الحزم وتسليمها.
- UDP
: يسمح بروتوكول UDP (بروتوكول مخطط بيانات المستخدم) للتطبيقات بإرسال رسائل ، تسمى مخططات البيانات ، إلى مضيفين آخرين على الشبكة.
بروتوكولات طبقة الإنترنت
يتم تكليف طبقة الإنترنت ، وتسمى أيضا طبقة الشبكة ، بإرسال وإعادة تجميع الشبكة packets بأكثر الطرق فعالية باستخدام عناوين الشبكة / عنوان IP لإرسال الحزم إلى وجهتها.
- IP
: بروتوكول الإنترنت الأولي (IP) ، جنبا إلى جنب مع بروتوكول TCP ، هو مجموعة من المتطلبات التي تحدد كيفية إرسال البيانات عبر الإنترنت.
- ICMP
: بروتوكول ICMP (بروتوكول رسائل التحكم في الإنترنت) هو بروتوكول شبكة يسمح لأجهزة الشبكة ، مثل أجهزة التوجيه ، بالمساعدة في تشخيص مشكلات الاتصال. بروتوكول اللجنة الدولية لشؤون المفقودين غير معني بالتبادل البيانات ، بدلا من ذلك الغرض منها هو التأكد من ما إذا كانت البيانات تصل إلى الوجهة المقصودة.
ربط بروتوكولات الطبقة
طبقة الارتباط هيمجموعة من طرق الاتصال التي تدير نقل البيانات بين الأجهزة المادية والشبكة.
- ARP
: بروتوكول/إجراء ARP (بروتوكول حل العناوين) لتعيين عناوين شبكة IP إلى عنوان جهاز فعلي، والمعروف باسم عنوان MAC.
MAC
: بروتوكول MAC (التحكم في الوصول المتوسط) يعطي الأجهزة رقم التعريف الفريد الخاص بها. يوفر وسيلة للشبكات للخداعct والتواصل مع الأجهزة.- Wi-Fi
: بروتوكول Wi-Fi (الدقة اللاسلكية) ، وهو أحد البروتوكولات التي نعتمد عليها جميعا في الحياة اليومية ، هو مجموعة من بروتوكولات الشبكة اللاسلكية التي تستخدم للاتصال بالوصول إلى الإنترنت والشبكات المحلية (LANs).
ما هي رموز الحالة ولماذا هي مهمة؟
هناك حتى ملحقات من بروتوكول HTTP ، والذي يتضمنdes HTTPS (بروتوكول نقل النص التشعبي الآمن) و WebDAV (التأليف الموزع وتعيين الإصدار المستند إلى الويب) ، والتي سنناقشها أكثر داخل رموز حالة HTTP ادناه. عندما يقدم عميل طلبا إلى الخادم، تتيح لك رموز الحالة معرفة ما إذا كان الطلب ناجحا أو فاشلا أو شيئا مختلفا. يتم الاحتفاظ برموز الحالة بواسطة هيئة الأرقام المخصصة للإنترنت، أو IANA، ويتضمن رموز الحالة من فرقة عمل هندسة الإنترنت (IETF) وجمعية الإنترنت (ISOC). كما هو محدد من قبل IANA منظمة، رفيما يلي خمسة تصنيفات لسمك القد حالة HTTPداط:
1xx: إعلامي – تم استلام الطلب ، واستمرار العملية
2xx: النجاح – تم استلام الإجراء بنجاح وفهمه وقبوله
3xx: إعادة التوجيه – يجب اتخاذ مزيد من الإجراءات من أجل إكمال الطلب
4xx: خطأ العميل – يحتوي الطلب على بناء جملة سيئ أو لا يمكن الوفاء به
5xx: خطأ في الخادم – فشل الخادم في تلبية طلب صالح على ما يبدو
الأفراد والمهندسين
بانتظام
اقترح رموز الحالة الجديدة من خلال طلبات Coمنتس (RFC), وستقوم فرقة العمل المعنية بهندسة الإنترنت بمراجعة ما يلي: تبني، و تقاعد حالة رموز حسب الضرورة.
شرح رموز حالة HTTP
توفر المعلومات أدناه نظرة عامة على جميع رموز حالة HTTP الأكثر شيوعا ، بالإضافة إلى رموز حالة HTTP التي نادرا ما يراها معظم الأشخاص أو حتى يعرفون وجودها. كما ذكرنا ، لا يتم رؤية الكثير من رموز الاستجابة أبدا من قبل المستخدمين ، لأنها قابلة للعرض فقط داخل الشبكة.
يحدد الرقم الأول من رمز الحالة الفئة ؛ ومع ذلك ، لا يلعب الرقمان الثانيان أي دور في زيادة تعريف رمز الحالة لنوع معين من الرسائل / الاستجابة. ضمن مجموعات التصنيف هذه، يمكن أن يكون هناك رموز حالة متعددة، وبعض المجموعات لديها رموز حالة أكثر من غيرها. وعلى الرغم من وجود أكثر من 60 رمزا فريدا رسميا للحالة ، إلا أن معظم الأشخاص لن يفعلوا ذلك إلا بشكل منتظم. تواجه حفنة أو اثنتين مع مرور الوقت.
يتم تفسير معظم رموز الحالة هذه ومعالجتها خلف الكواليس. سترى أيضا أن هناك مجموعات من الرموز التي تم تصنيفها على أنها “غير معينة”. في حين أن معظم رموز الحالة التي نراها اليوم قد تم توحيدها ولديها لا تتغير هذه الأرقام غير المخصصة بمرور الوقت ، مما يترك مجالا لإنشاء رموز حالة إضافية حسب الضرورة. بالإضافة إلى ذلك ، على الرغم من أن بعض رموز المستخدم غير المعينة ليست سابقا جزءا من معيار HTTP (بروتوكول نقل النص التشعبي) ، إلا أن هناك شركات تستخدمها على أنها استجابة الخادم المخصصة للمستخدمين ، مما يسمح للشركات باستكشاف المشكلات التي قد يواجهها المستخدمون وإصلاحها بشكل أفضل. انقر فوق روابط المستندات المرجعية RFC في القائمة أدناه للحصول على التفاصيل الكاملة لرمز حالة HTTP المحدد.
قائمة كاملة ونظرة عامة على رموز حالة HTTP
1
xx
رموز الحالة
:
معلوماتية
ال 1xx-مستوى رموز حالة HTTP تخبر المستخدمين أن الطلب الذي هم امتلك صنع وقد تم تلقى ولكن لا يزال يعالج. رموز الحالة 1xx تفعل لا يعني بالضرورة أن هناك مشكلة ، فإنه أناهناك فقط للسماح لك بشيء لا يزال في طور الإكمال. متضمن في هذه المجموعة ليست سوى حفنة من 1xx الرموز التي قد يصادفها المستخدمون وتحتاج إلى أن تكون على بينة.
100
: متابعة
يخبرك رمز Status 100 Continue أنه تم استلام جزء من الطلب دون أي مشاكل. في هذه النقطة كل شيء هو حسنا ولكن لا يزال قيد التنفيذ. إذا كان الجزء المتبقي من لا يتم رفض الطلب ، الخدمةr سيرسل ردا نهائيا بمجرد اكتمال الطلباد. إذا تم رفض رؤوس HTTP ، فهذا يضمن أن العميل يفعل ذلك لا إرسال طلب للجسم. ومع ذلك ، إذا كان الطلب هل لا يخدعحقل رأس ، ثم سيتجاهل المتصفح ببساطة respons e. See RFC7231 ، القسم 6.2.1
لمزيد من المعلومات.
101: تبديل البروتوكولات
تم إنشاء العديد من بروتوكولات HTTP منذ البدايات المتواضعة للإنترنت. كان أول إصدار موثق من بروتوكول HTTP هو HTTP 0.9. التكرار الحالي هو HTTP 2.0 أو HTTP/2. رمز الحالة 101 يشير تبديل البروتوكولات إلى التي يقبلها الخادم طلب العميل للتبديل إلى بروتوكول HTTP مختلف من خلال حقل رأس الترقية. عندما يقدم متصفح طلبا للحصول على صفحة، قد يتلقى ال رمز حالة HTTP 101 ثم رأس الترقية، whiالفصل يشير يتم التبديل إلى إصدار HTTP مختلف. أخيرا ، يفترض أن الخادم سيوافق على تبديل البروتوكولات فقط عندما يكون ذلك مفيدا ، مثل الترقية / التبديل إلى بروتوكول أحدث مقابل بروتوكول أقدم. See RFC7231، القسم 6.2.2
لمزيد من المعلومات.
102: تجهيز
A status code 102 يتم استخدام المعالجة فقط مع WebDAV (التأليف وتعيين الإصدار الموزع على الويب). معظم الصفحات للقراءة فقط. WebDAV هو امتداد ل HTTP بروتوكول يمنح العملاء القدرة علىتحرير المحتوى عن بعد ونقل الملفات. ال ويب داف تم إنشاء بروتوكول لمنح المستخدمين القدرة على كولوكيراته على الملفات مع الآخرين, مثل دروببوإكس أو جوجل درايف. رمز الحالة 102 هوn رمز الاستجابة المؤقت ، يخبر العميل بأن الخادم قد قبل الطلب الكامل ، ولكن لم يكمل الطلب. يتم إرسال رمز حالة HTTP هذا فقط بواسطة الخادم لو a يستغرق الطلب وقتا أطول من 20 ثانية. رأى
RFC2518
، القسم 10.2
لمزيد من المعلومات.
103: تلميحات مبكرة
رموز الحالة 10
3 التلميحات المبكرة
قيد
التقييم حاليا/
المرحلة التجريبية. رمز الحالة هذا سيتم استخدامها عند التحميل المسبق للمحتوى/الموارد الخارجية. يسمح بروتوكول HTTP / 2 بدفع المحتوى لتسريع التسليم ، حتى يتمكن مطورو الويب من دفع محتوى معين أثناء انتظار تحميل موارد خارجية أخرى. هذا مفيد من وجهة نظر المستخدم النهائي لأنه يقلل من وقت التحميل المدرك. Tرمز استجابة HTTP الخاص به أشار إلى متصفح يكون الخادم سترسل استجابة نهائية
، إلى جانب حقول الرأس المضمنة في الاستجابة.
S
ee
لمزيد من المعلومات
104-199: غير معين
رموز الحالة من 104 إلى 199 غير معينة حاليا.
2xx رمز الحالة: النجاح
رموز حالة HTTP على مستوى 2xx تشير إلى أن طلب العميل من الخادم تماستلامه ومعالجته. على عكس رموز الحالة 4xx ، فإن رموز الحالة 2xx هي ما تريد الحصول عليه. مثل رموز الحالة 1xx ، تتم معالجة رموز الحالة 2xx خلف الكواليس ونادرا ما يراها المستخدمون ، إلا إذا كانوا يستخدمون أدوات المطور أو تحسين محركات البحث لرؤية جميع استجابات HTTP للصفحة.
200: موافق
يستخدم رمز الحالة 200 OK ، أحد رموز حالة HTTP المستخدمة على نطاق واسع ، للإشارة إلى أنه تم استلام الطلب ومعالجته ونجاحه. ومع ذلك ، اعتمادا على طريقة الطلب المستخدمة (GET ، HEAD ، POST ، PUT ، DELETE ، OPTIONS ، TRACE). على سبيل المثال، إذا كان الطلب عبارة عن طلب GET، فستتضمن الاستجابة المورد. إذا كان هل أي من إعادة أخرىالمهام ، ستشمل الاستجابة نتيجة الإجراءات. ال 200 حالة الرمز هو واحد من أكثر من 10 رموز استجابة أخرى التي هي أيضا قابلة للتخزين المؤقت، وهذا يعني أنه يمكن حفظها واسترجاعها عبر العميل ، حتى لا تضطر إلى تقديم طلب آخر إلى الخادم في المستقبل. Sه RFC7231، القسم 6.3.1 لمزيد من المعلومات.
201: تم الإنشاء
يشبه رمز الحالة 201 الذي تم إنشاؤه رمز حالة 200 OK ، ومع ذلك، فإن رمز الحالة 201 يعني أنه تمت معالجة الطلب بنجاح، وأنه أعاد، أو أنشأ، موردا أو إعادة توجيه في العملية. A يستخدم رمز الحالة 201 عادة لطلبات PUT. على سبيل المثال ثhen يتم استخدام طلب PUT ، يتم إنشاء مورد جديد على عنوان URL المحددة في الطلب. إذا كان هناك رمز حالة 201 في طلب POST، فهذا يعني أنه تم إنشاء مورد في نقطة نهاية/موقع مختلف لواجهة برمجة التطبيقات. See
RFC7231، القسم 6.3.2
لمزيد من المعلومات.
202: مقبول
ال 202 قبلت حالة رمز يعني أن الخادم لديه تلقى طلبا للمعالجة ، ومن أناتم قبوله ، ولكن يحتوي الطلب على لا تم الانتهاء منه. كما أنه يفعل لا يعني أنه سيتم قبول الطلب في نهاية المطاف ، لأنه يعتمد على وقت حدوث المعالجة الفعلية. يظهر هذا النوع من الطلبات عادة في واجهات برمجة التطبيقات حيث يتم تشغيل عملية دفعة واحدة في اليوم. منذ هناك هل لا توجد طريقة ل HTTP للتواصل بعد نجح الطلب أو تم إغلاق اتصال المستخدم، قد ترسل واجهة برمجة التطبيقات رسالة بريد إلكتروني إلى مستخدم nالتوثيق هم أن العملية قد نجحت. Sه RFC7231 ، Section 6.3.3 لمزيد من المعلومات.
203: معلومات غير موثوقة
عادة ما يتم استخدام رمز حالة المعلومات غير الموثوقة 203 بواسطة وكيل HTTP أو جهة خارجية. الوكيل، يجلس بين العميل والخادم قد يغير الردود قبل الوصول إلى العميل. ل أشار أن شيئا ما قد تغير خلال العملية ، يتم استخدام رمز الحالة 203. ومع ذلك ، فإن عيب هذه الطريقة هو أن انها أناق لا يمكن معرفة ما هو رمز الحالة الأصلي إذا قام وكيل بتغيير شيء ما في الاستجابة. الحل البديل المقترح هو استخدام رأس تحذير جنبا إلى جنب مع 214 حالة رمز الذي يتم استخدامه ل تشيرe إلى أن هناك تغييرا أو تعديلا في respعلى. باستخدام wيسمح رأس arning لرمز الحالة الأصلي ب مرت ثروغH. S ee RFC7231, Section 6.3.4
لمزيد من المعلومات.
204: لا يوجد محتوى
رمز الحالة 204 لا يوجد محتوى يشير أن الاستجابة قد تم تسليمها بنجاح من قبل الخادم والوفاء بها وليس هناك أي متابعة أخرىيتم إرسال الأنف والحنجرة في جسم الاستجابة. وكمثال على ذلك، إذا تم إرسال الطلب في النموذج الموجود على صفحة ، بمجرد إجراء respoيتم إرسال nse ، العميل/المتصفح ليس من المفترض أن يغير العرض ، مما يعني أن النموذج يجب أن لا أن تكون منتعشة أو مباشرة المستعملون إلى صفحة جديدةe. لا يجب استبدال محتوى إضافي أو الظهور من حيث وجهة نظر المستخدم. S ee RFC7231, Section 6.3.5
لمزيد من المعلومات.
205: إعادة تعيين المحتوى
مثل 204 لا توجد حالة محتوى code، رمز الحالة 205 إعادة تعيين المحتوى يشير إلى أن الخادم قد أرسل الطلب بنجاح ويتطلب من وكيل المستخدم تحديث / إعادة تعيين طريقة العرض إلى أوi الخاص بهالحالة الجينالية. إذا استخدمنا مثال نموذج على صفحة ، فبمجرد المستخدم يكمل و إرسال النموذج ، يجب على العميل / المتصفح مسح النموذج مرة أخرى إلى حالته الأصلية حتى يتمكن المستخدم من اتخاذ إجراء فوآر تي . A يفترض رمز الحالة 205 أنه لن يتم توفير أي محتوى آخر. See RFC7231، القسم 6.3.6
لمزيد من المعلومات.
206:
المحتوى
الجزئي
أ 206 يمكن استخدام رمز حالة المحتوى الجزئي لمجموعة متنوعة من الطلبات وعادة ما يكون يشير أن الخادم قد أنجزت جزئي طلب مورد. على سبيل المثال، إذا كان العميل يبحث فقط عن عميل معين جزء، أو النطاق، من a خاص مورد أو صفحة. مثال آخر على المكان الذي 206 حالة يتم استخدام الرمز هو في الفيديو. يجوز للعميل التحميل فقط الفيديو في أجزاء لعدم الاضطرار إلى الانتظار حتى يتم تخزين الفيديو مؤقتا أو تحميله ، مما يساعد على تجنب تجربة المستخدم السلبية حيث سيتعين على المستخدم الانتظار لفترة أطول قبل تشغيل الفيديو. هذه هي أفضل الممارسات العادية بين مشغل فيديو HTTPs لتجنب عرض النطاق الترددي ومشكلات الكمون المتصورة . See RFC7233، القسم 4.1
لمزيد من المعلومات.
207: متعدد الحالات
ال 207 متعدد الحالات حالة رمز يوفر حالة عمليات مستقلة متعددة وتستخدم من قبل خوادم WebDAV. الرسالة/الاستجابة الافتراضية هي رسالة نصية/XML. ومن يشير أن عمليات متعددة قد حدثت وأنه يمكن عرض حالة كل عملية في نص respأونس. يمكن أن تختلف رموز الحالة بين أي فئة من الفئات الخمس. تختلف رموز الاستجابة حسب عدد الطلبات الفرعية. على عكس 200 ستاتو الأخرىرموز s ، رمز الحالة 207 لا تأكد من نجاح العملية. يحتاج العميل إلى عرض نص كل طلب إلى تحديد ما إذا كان ناجحا أم لا. See RFC4918، القسم 11.1
لمزيد من المعلومات.
208: تم الإبلاغ عنها بالفعل
ال 208 تم الإبلاغ عنه بالفعل حالة الرمز هو رمز حالة آخر يستخدم داخل ملحق WebDAV. مثل ال 207 حالة رمز ، فإنه يسمح للعميل / المتصفح ب أشار إلى الخادم الذي تمت معالجة الموارد بالفعل. عندما يطلب العميل الموارد، قد يكون من الممكن أن تتضمن الاستجابة موارد مكررة، مما يعني أنه سيتم إرسال نفس الموارد عدة مرات، وهو أمر زائد عن الحاجة. ال 208 استجابة الحالة تتجنب إمكانية المعالجة والتكرار نفس الاستجابة. 208 رمز الحالة الاستجابات سيظهر فقط في نص الاستجابة وليس كاستجابة HTTP فعلية. See RFC5842، القسم 7.1
لمزيد من المعلومات.
209-225: غير معين
رموز الحالة من 209 إلى 225 غير معينة حاليا.
226:
الدردشة
المستخدمة
يتم استخدام رمز الحالة المستخدم 226 IM (معالجات المثيلات) للإشارة إلى أن الخادم قد أكمل طلب GET للحصول على مورد، ولكن الاستجابة تمثل معالجة مثيل واحد أو عدة عمليات معالجة تم تطبيقها على المثيل الحالي. يوجد ضمن بروتوكول HTTP ملحق يسمى ترميز Delta في HTTP مدعوم على جانب الخادم. إذا كان هذا يعني ضمناented، يمكن للعميل طلب تغييرات على الإصدار المخزن مؤقتا، وسيقوم الخادم بإرسال التغييرات بدلا من إعادة إرسال مصدر إعادة التشغيل بالكامل مرة أخرى. لتتمكن من تنفيذ هذه الميزة ، يحتاج طلب العميل / المتصفح إلى حدد نوع المراسلة الفورية المدعومة. إذا كان الخادم يدعم هذه الميزة أيضا ، فسيستجيب باستخدام 226 رمز الحالة والتغييرات. إذا كان يتم إرسال رمز الحالة 200 مرة أخرى ، مما يشير إلى أن الميزة غير مدعومة. See RFC3229، القسم 10.4.1
لمزيد من المعلومات.
227-299: غير معين
رموز الحالة من 227 إلى 299 غير مخصصة حاليا.
3xx: إعادة التوجيه
يتم استخدام رموز الحالة 3xx في حالات إعادة توجيه عنوان URL. تتغير مواقع الويب وتتطور دائما ، لذلك قد تكون هناك أوقات يحتاج فيهاالطيارون إلى توجيه المستخدمين إلى صفحة محدثة أو مختلفة. تساعد عمليات إعادة التوجيه في تخفيف المستخدمين من الاضطرار إلى البحث عما يبحثون عنه والحفاظ عليه ترتيبك في محركات البحث. قد يتم تنفيذ إجراءات إعادة التوجيه بواسطة المتصفح تلقائيا أو قد تتطلب تفاعلا إضافيا من المستخدمين. تعد رموز حالة 3xx HTTP حيوية لكبار المسئولين الاقتصاديين (تحسين محركات البحث) وتجربة المستخدم ، بالإضافة إلى إخبار محركات البحث بالمحتوى الذي تريد منهم الزحف إليه وفهرسته. أنا(و) لم تنفذ على النحو الصحيح، قد يتم توجيه المستخدمين إلى موقع غير مقصود ، مما قد يؤدي إلى رمز حالة 4xx ويمكن أن يؤثر على نقاط جودة تحسين محركات البحث.
300: خيارات متعددة
يشير رمز الحالة 300 Multiple Choices إلى أن resource قد تم نقله ويمكنه إعادة التوجيه إلى مواقع متعددة. في هذه الحالة المستخدم يجب أن تقرر أي مورد لاستخدامه. قد يكون الخادم أشار خيار مفضل و التي ينبغي أن تكون اشارت في الرأس ميدان حيث يمكن لوكيل المستخدم إعادة التوجيه إلى الخيار المفضل تلقائيا. في الاستخدام العملي ، رنادرا ما يتم استخدام رمز الحالة الخاص به حيث لا توجد طريقة موحدة للاختيار من بين استجابات متعددة. Sه RFC7231، القسم 6.4.1 لمزيد من المعلومات.
301: تم نقله بشكل دائم
يتم استخدام رمز الحالة 301 تم نقله بشكل دائم للإشارة إلى أنه تم نقل مورد هدف إلى موقع دائم. يخبر رمز الحالة 301 المتصفح/العميل باستخدام هذا الموقع الجديد أو عنوان URL الجديد من الآن فصاعدا في الرأس. جنبا إلى جنب مع 301 حالة الرمز ، سيكون عنوان URL الجديد نظرا في الرد بالإضافة إلى تحديث أي عناوين URL في سابق مكان(ق)، إلى جانب التحديث إلى عنوان URL الجديد. Sه RFC7231، القسم 6.4.2 لمزيد من المعلومات.
302: وجدت
رمز حالة تم العثور عليه 302 يشير إلى عميل/متصفح إلى أن المورد الذي يصلون إليه مؤقت الموقع تحت موقع مختلف. على عكس رمز الحالة 301 ، يشير رمز الحالة 302 إلى حركة مؤقتة ، لذلك يجب على العميل عدم القيام بذلك تلقائيا تحديث لها الصلات إلى الموقع الجديد، كما هو الحال مرة أخرى، فإنه أناs من المفترض أن تكون مؤقتة. مثال على المكان الذي 302 حالة يجب استخدام الرمز إذا كان هناك هي ضعف عناوين URL، لكنهم يمكن خدمتها في لغات مختلفة. قد يصل المستخدم إلى عنوان URL محدد، ولكن يمكن للعميل إعادة توجيهه تلقائيا إلى tانه الصفحة المناسبة على أساس إعدادات المتصفح الخاصة بهم واستخدام هذا سن الزيارات اللاحقة. انها طق إلى أنه في بعض الحالات، قد تغير المتصفحات طلبا من POST إلى GET. في حالة أن هذا الإجراء هو غير صالح، يجب استخدام رمز الحالة 307. See RFC7231، القسم 6.4.3
لمزيد من المعلومات.
303: انظر أخرى
يشير رمز الحالة 303 انظر أخرى إلى أن الخادم سيقوم بإعادة توجيه العميل / المتصفح إلى مورد آخر. سيكون المورد المشار إليه كعنوان URL حقل الرأس. على عكس رموز الحالة 301 و 302 ، فإنه يفعل ذلك لا يعني أن المورد له فترة زمنيةريly أو دائم التحرك ، فإنهالقصد من ذلك هو تحديد عنوان URL إلى حيث الاستجابة ل specifأناc يمكن أن يكون الطلب أنشأ عن طريق طلب GET. يجب أن يكون 303 رموز الحالة لا يتم تخزينها مؤقتا ، ومع ذلك ، فإن الاستجابة ل لاحق قد يتم تخزين الطلب مؤقتا. استخدام نموذجي ل 303 حالة سيكون الرمز لضمان المستخدمين do لا إعادة الإرسال عن طريق الخطأ بيانات النموذج عن طريق طلب POST. يجب توجيههم إلى صفحة جديدة. إذا لم يكن الأمر كذلك ، فقد ينقرون دون علم زر الرجوع في متصفحهم ، والذي قد يطلب منهم إعادة الإرسال مرة أخرى ، مما يؤدي إلى unnecessary () الازدواجية فيالتقديمات. See RFC7231، القسم 6.4.4
لمزيد من المعلومات.
304: لم يتم تعديله
رمز الحالة 304 يتم إرسال “غير معدل” استجابة لطلب GET أو HEAD مشروط. يمكن للعملاء/المتصفحات إرسال طلب مشروط، مثل إذا-مطابقة
، إذا-لا-مطابقة
، إذا-معدلة-منذ، إذا-غير معدلة-منذ
، أو If-Range
، السؤال عما إذا كان قد تم تعديل مورد معين أم لا منذ تاريخ / وقت محدد. هذا هل يتم ذلك فقط إذا كان العميل قد قام مسبقا بالوصول إلى المورد وتنزيله وحفظه. إذا كان قد تم تم التعديل منذ آخر تاريخ / وقت محدد تم الوصول إليه ، سيقوم الخادم بإرجاع رمز حالة موافق 200. إذا كان لديه لا تم تغييرها منذ ذلك التاريخ / الوقت ، الحالة 304 يتم إرسال الرمز كرد فعل, تبين أنه ينبغي خدمة المورد المحفوظ لأنه يحتوي على لا تم تعديل منذ آخر مرة تم الوصول إليها. Sه RFC7232، القسم 4.1 لمزيد من المعلومات.
305: استخدام الوكيل
رمز حالة 305 استخدام الوكيل is رمز حالة مهمل لم يعد يستخدم بسبب اعتبارات أمنية. ومن تم استخدامه ل أناndicate إلى عميل أنه يجب الوصول إلى الدقة التيكانوا يصلون إليها عبر وكيل. لمزيد من المعلومات حول رمز حالة الوكيل 305 استخدام، راجع RFC7231، القسم 6.4.5
306:
غير مستخدم
مثل رمز الحالة 305 ، حالة 306 غير المستخدمة كان يعرف في الأصل باسم وكيل التبديل. ال تم استخدام رمز الحالة 306 في سابقة مواصفات. وكان القصد منه أن يستخدم على النحو الوارد في إشارة إلى العميل بأن عمليات إعادة الطلب اللاحقة إلى مورد يجب أن تستخدم الوكيل الذي تم تحديده. تم اعتبار هذا مشكلة أمنية ، لذلك لم يعد يتم استخدامه. لمزيد من المعلومات حول رمز الحالة 306 غير المستخدم، راجع RFC7231، القسم 6.4.6
307: إعادة التوجيه المؤقت
مثل رمز حالة إعادة التوجيه 302 تم العثور عليه، رهو 307 إعادة التوجيه المؤقت حالة رمز يشير إلى العميل/المتصفح الذي يتوفر مورد أو مستند في مكان مختلفمؤقت عنوان URL وإرجاع عنوان URL هذا. نظرا لأن إعادة التوجيه مؤقتة ويمكن أن تتغير ، يجب أن يستمر المتصفح/العميل في الوصول إلى عنوان URL الحالي ل لاحق الطلبات. الفرق الرئيسي بين 302 حالة الرمز و الحالة 307 رمز هو أن الحالة 307 الرمز لا يسمح بتغيير الطلبات من a منصب طلب إلى حصل طلب، لذلك إذا طلب العميل طلب POST، إعادة توجيهه و بادر طلب POST مرة أخرى. Sه RFC7231، القسم 6.4.7
308: إعادة التوجيه الدائم
رمز حالة إعادة التوجيه الدائم 308 هو رمز حالة قابل للتخزين المؤقت (ما لم يتم تنفيذ عناصر تحكم ذاكرة التخزين المؤقت) يشير إلى أن المورد الهدف موجود الآن في عنوان URL دائم و subsequent يجب توجيه الطلبات إلى عنوان URL هذا أيضا. بالإضافة إلى ذلك، يجب على العميل تحديث أي الإشارات المرجعية القديمة إلى الموقع الجديد. يشبه رمز الحالة 308 إلى حد كبير رمز الحالة 301 ، ومع ذلك ، إذا تم إرسال رمز حالة 308 ، فيجب على cl ient أن بادر وإرسال نفس الطلب على الموقع المستهدف. A رمز الحالة 301 لا يوجدt يجب أن تفعل هذا. تقوم معظم المتصفحات / العملاء بتغيير طلب POST إلى GET request. See RFC7238, Section 3
لمزيد من المعلومات.
309-399: غير معين
رموز الحالة من 309 إلى 399 غير مخصصة حاليا.
4xx: خطأ العميل
التصنيف الذي يحتوي على معظم رموز حالة HTTP ، رموز حالة HTTP 4xx ليست ما تريد أن يراه المستخدمون. أي رمز حالة يبدأ ب 4 يعني أن هناك مشكلة مع العميل. عادة ما يتم إنشاء رموز الحالة 4xx إذا تم حذف صفحة ولم تتم إعادة توجيهها، أو إذا تم إدخال شيء ما بشكل غير صحيح داخل عنوان URL أو رابط. إذا حصل المستخدمون على رمز حالة 4xx اللعين ، فهذا يعني أن هناك مشكلة مع العميل / المتصفح تلقي المعلومات من الخادم. هذه هي الأخطاء التي سيراها المستخدمون منبثقة على شاشاتهم و خلق تجربة مستخدم سلبية ، مما يؤدي إلى القليل من الإحباط ولهم تبحث في مكان آخر. إذا زحفت محركات البحث إلى موقعك وتلقت خطأ 404، على سبيل المثال، فسيظهر هذا كخطأ في التقرير. A عدد قليل من أخطاء 404 على ما يرام ومحركات البحث لا تنظر إليها بالضرورة على أنها شيء سلبي ، ولكن 404 الذي يعيد التوجيه إلى 404 يمكن أن تؤثر سلبا على كبار المسئولين الاقتصاديين الخاص بك. ليس ذلك فحسب ، إذا تم استخدام الصفحة المعنية لزيادة عدد الزيارات أو المبيعات ، فقد يؤدي ذلك إلى خسارة في الإيرادات المحتملة.
400: طلب سيئ
طلب سيئ 400 رمز حالة الخطأ يعني أن الخادم لا يمكنه معالجة الطلب بسبب مشكلة من العميل. هذا يمكن أن يكون بسبب أي عدد من الأسباب ، مثل كون الملف كبيرا جدا ، وبناء جملة سيئ ، عنوان URL غير صالح ، أو بعض المشكلات الأخرىالتي يستخدمها تطبيق تابع لجهة خارجية ، وهذا هو السبب في استخدام رمز الحالة 400 في بعض الأحيان كرمز حالة للقبض على جميع ، حتى إذا كانت هناك مشكلة على جانب الخادم. هذا يمكن أن يجعل استكشاف الأخطاء وإصلاحها 400 حالة رمز أكثر قليلا مضيعة للوقت وصعبة، ومع ذلك، جنبا إلى جنب مع 400 حالة خطأ في التعليمات البرمجية ومعلومات الرأس ، tهو يمكن أن يوفر الخادم زائد الاستجابة على طول الطرافةح ذلك، والتي يمكن عرضها على ال المستخدم للمساعدة تحديد المشكلة وتسهيل عملية استكشاف الأخطاء وإصلاحها وتشخيصها. Sه RFC7231، القسم 6.5.1 لمزيد من المعلومات.
401: غير مصرح به
خطأ غير مصرح به 401 يشير رمز الحالة إلى أن الطلب لا يتضمن بيانات اعتماد المصادقة المناسبة أو فشل المصادقة أو يجب على المستخدم تسجيل الدخول. يتطلب العميل المصادقة من الخادم. غالبا ما يتم استخدام المصطلحات المصرح بها والمصادق عليها بالتبادل ، ولكن إنها تعني أشياء منفصلة. A رمز الحالة 401 هو ستريكتلي المعنية مع المصادقة. في الحالات التي ترغب فيها في إبلاغ العميل بأنه غير مسموح به إطلاقًا، ثم رمز الحالة 403 ينبغي تنفيذها. According إلى المواصفات ، ال الحالة 401 يجب أن يتضمن الرمز أيضا WWW-المصادقة رأس من الخادم استجابه, تبين للعميل ما هو نظام المصادقة أو طريقة الخادم مطلبداط. Sه RFC7235، القسم 3.1 لمزيد من المعلومات.
402: الدفع مطلوب
إنشاء d في الأصل كجزء من طريقة للسماح بالإمكانات طرق الدفع الرقمية المستقبلية، خطأ الدفع المطلوب 402 رمز الحالة محجوز رسميا للاستخدام المستقبلي ، لكنه استخدم بعض المحدود ، ولكن النادر ، المواقف. لمزيد من المعلومات حول رمز الخطأ 402 الدفع المطلوب ، راجع RFC7231، القسم 6.5.2
403: ممنوع
ال 403 يشير رمز حالة الخطأ المحظور إلى أن الطلب من العميل قد تم فهمه ، لكن الخادم لن يأذن به ، لذلك لا يمكن للعميل الوصول إليه. يمكن للخادم أن يعرف السبب في عدم التصريح بالطلب ضمن الاستجابة ، والذي قد يكون راجعا إلى أسباب مختلفة مثل كلمة المرور أو اسم المستخدم غير الصحيح . على عكس الحالة 401 التعليمات البرمجية ، والتي تتطلب المصادقة ، الحالة 403 يمكن للكود أشار أن العميل ليس لديه إذن حقا للوصول إلى هذه الموارد، لذا المصادقة في هذه الحالة هل لا ممكن. Sه RFC7231، القسم 6.5.3 لمزيد من المعلومات.
404: غير موجود
واحدة من رموز الحالة الأكثر شيوعا وسيئة السمعة التي تمت مواجهتها بواسطة المستخدمين والمطورين، و 404 لم يتم العثور عليها خطأ رمز الحالة يشير أن المورد مطلوب من الخادم لا لا موجود أو موجود لار على استعداد لتوفيره للعميل. A الحالة 404 رمز لن أشار ما إذا كان الe عدم وجود توفير المورد بشكل مؤقت أو دائم ، ولكن يمكن للعميل تقديم طلبات فرعية للوصول إليه. في الحالات التي يعرف فيها أن الموارد قد اختفت بشكل دائم ، يجب أن يكون رمز الحالة 410 مستعمل. رموز الحالة 404 ، افتراضيا ، قابلة للتخزين المؤقت أيضا ، ما لم تتحكم ذاكرة التخزين المؤقت الأخرى are in place. See RFC7231، القسم 6.5.4
لمزيد من المعلومات.
405: الطريقة غير مسموح بها
رمز حالة الخطأ “الطريقة 405 غير مسموح به” يشير إلى أن موردا معينا يطلبه العميل غير مدعوم من قبل الخادم. طريقة 405 غير مسموح بها هي مثل و 403 لومع ذلك، فإن رمز الحالة المزايد عليه الحالة 403 رمز يشير أن المورد قد يكون متاحا، فإنه أناق فقط أن العميل يفعل لا الحصول على الإذن اللازم لتنفيذ الطلب. جنبا إلى جنب مع حالة 405 طريقة غير مسموح بها ، يجب على الخادم أشار ال appropriaتي و مدعم أساليب للمورد المستهدف. لمزيد من المعلومات حول رمز الخطأ 405 Method غير مسموح به، راجع RFC7231، القسم 5.5.6
406: غير مقبول
مثل رمز حالة الخطأ 405 Method Not Allowed، يشير رمز الخطأ 406 غير المقبول إلى عدم وجود دعم لطلب معين. في هذه الحالة the 406 رمز الحالة غير مقبول يشير إلى أن الخادم فهم الطلب، ولكن الاستجابة ليست بدعم أو فهم من قبل العميل. يمكن للعميل طلب إصدارات محددة من مورد في الرأس، مثل A-IM أو قبول اللغة, من بين أمور أخرى، ولكن إذا كان الخادم هل لا دعم ذلك ، فإنه يستجيب مع رمز الحالة 406 غير مقبول. يمكن للخادم إما الرد بقائمة الموارد المناسبة المعرفات التي يمكن للعميل اختيارها من. Sه RFC7231، القسم 6.5.6 ل مورe معلومات.
407: مصادقة الوكيل مطلوبة
مصادقة الوكيل 407 المطلوبة خطأ sرمز تاتوس هو مثل رمز الحالة 401 غير المصرح به، ومع ذلك، في حالة الحالة 407 رمز من أجل استخدام وكيل ، يجب أولا مصادقة العميل. يجب على الوكيل إرجاع طريقة المصادقة. ليس شائعا اليوم بسبب صعود الشبكات الافتراضية الخاصة والوكلاء العمل كوسطاء بين المستخدمين / العملاء والإنترنت ، السماح للمستخدمين بالوصول إلى الموارد بسرعة أكبر ، حيث أن المحتوى نموذجيا المخزنه مؤقتا، ويمكن أيضًا توفير طبقة من الأمان وإخفاء الهوية للمستخدمين. لمزيد من المعلومات حول رمز الخطأ 407 مصادقة الوكيل المطلوبة، راجع RFC7235، القسم 3.2
408: مهلة الطلب
يعني رمز حالة الخطأ 408 Request Timeout أن الخادم لم يتلق طلبا من العميل في فترة زمنية محددة. يمكن أن يكون الطلب المتأخر من العميل راجعا لمجموعة متنوعة من الأسباب ، مثل الاتصال البطيء أو المعطل. بمجرد مرور ذلك الوقت ، يتم إرسال حالة مهلة الطلب 408 بواسطة الخادم ويمكن للمستخدم / العميل إعادة إرسال الطلب مرة أخرى. لمزيد من المعلومات حول رمز الخطأ 408 طلب مهلة، راجع RFC7231، القسم 6.5.7
409: الصراع
صراع 409 خطأ رمز الحالة يشير أن الطلب المقدم من العميل يمكن أن لاt تتم معالجتها بسبب تعارض مع الخادم. كان الطلب من العميل على ما يرام ، ولكن هناك كانت المشكلات الموجودة على جانب الخادم والتي تمنع تنفيذ الطلب. مثال على ذلك يمكن أن يكون إذا كان هناك طلب لتحرير ملف معين ، حذف(د)، أو تم إنشاؤها بواسطة المستخدم ، ولكن هذه الوظائف غير مسموح بها. جنبا إلى جنب مع استجابة 409 ، يجب على الخادم إرجاع إرشادات حول كيفية حل المستخدم لهذه المشكلة أو indicate لماذا المشكلة هي happenrinز. See RFC7231، القسم 6.5.8
لمزيد من المعلومات.
410: ذهب
مثل رمز حالة الخطأ 404 لم يتم العثور عليه الذي قمنا بتغطيته سابقا ،يشير رمز الحالة 410 Gone إلى أن المورد الذي يطلبه العميل قد تمت إزالته ولم يعد متاحا من الخادم. No يتم توفير مزيد من المعلومات من حيث إعادة توجيه عنوان URL أو مكان الوصول إلى المورد. تمت إزالته إلى أجل غير مسمى. لمزيد من المعلومات حول رمز الخطأ 410 Gone ، راجع RFC7231 ، القسم 6.5.9
411: الطول المطلوب
يشير رمز حالة الخطأ 411 الطول المطلوب إلى أن الخادم لا يسمح بالطلب من العميل بسبب نص طلب محدد مسبقا content length. يمكن تكرار الطلب من قبل العميل إذا تم تحديد رأس طول محتوى صالح في طلب المورد اللاحق. لمزيد من المعلومات حول رمز الخطأ المطلوب بطول 411، راجع RFC7231، القسم 6.5.10
412: فشل الشرط المسبق
الطلبات الشرطية إلى الخادم مسموح بها كجزء من بروتوكول HTTP. إذا كان الحق يتم استيفاء الشروط في الطلب ، ويتم تنفيذ الطلب ومعالجته بواسطة الخادم. يعني رمز حالة الخطأ 412 Precondition Failed (فشل) أن شرطا واحدا أو عدة شروط في رأس الطلب قد فشل. على سبيل المثال ، يمكن استخدام هذا في طلبات GET أو أ الطلب المشروط هو استخدام ل إعادة تشغيل المورد فقط إذا كان هذا المورد هاق تغيير. لمزيد من المعلومات حول رمز الخطأ 412 فشل الشرط المسبق، راجع RFC7232، القسم 4.2
413: طلب كيان كبير جدا
ال 413 طلب كيان كبير جدا خطأ رمز الحالة يشير أن الخادم wلا مرض قبول الطلب ومعالجته من duه للطلب جسم أن تكون أكبر من الخادم السماح أو يمكن عملية. تتضمن هذه الأمثلة تحميل ملف حيث الملف يتجاوز الحد الاقصي حجم التحميل تم تعيينه بواسطة الخادم أو عند تجاوز الحد الأقصى لعدد التحميلات. في الحالات التي يكون فيها الe 413 طلب كيان خطأ كبير جدا يحدث، قد يقوم الخادم بإغلاق الاتصال تماما لمنع العميل من الاستمرار في إرسال الطلب. في بعض الحالات, انها أناs من المحتمل أن ملقم سيسمح للعميل بإعادة محاولة الطلب، إذا كانأناق حالة مؤقتة ، و يجب أن تتضمن هذه الرسالة مرة أخرى إلى العميل. هاويفإيه ، فإنه أنامن الممكن أن يتسبب الطلب في نفاد الخادم نفسه من الناحية المادية مساحة القرص. في هذه الحالة، يكون الخطأ 507 “تخزين غير كاف” هو الاستجابة التي يجب أن يتلقى العميل مرة أخرى. See RFC7231، القسم 6.5.11
لمزيد من المعلومات.
414: URI طويل جدا
ليست استجابة خادم شائعة جدا ، يعني رمز حالة الخطأ 414 URI Too Long أن الخادم رفض طلب العميل بسبب عنوان URL أطول مما يمكن للخادم معالجته. اخيتضع wsers ومحركات البحث قيودا على طول عناوين URL ، جزئيا لتجنب هجمات DDoS أو أخطاء التعليمات البرمجية ، ولكن مسار عنوان URL أو HTTP لا لها حدود صريحة. لذلك ، إذا كان ليmit يتجاوز ما تم تعيينه بواسطة الخادم ، سيحدث خطأ 414 URI Too Long. لمزيد من المعلومات حول رمز الخطأ 414 URI Too Long، راجع RFC7231، القسم 6.5.12
415: نوع الوسائط غير المعتمدة
رمز حالة الخطأ 415 نوع الوسائط غير المعتمدة يشير إلى أن الخادم لا يمكنه معالجة نص الطلب، أو جزء من نص الطلب، بسبب تنسيق وسائط غير مدعوم. حتى إذا كان الطلب من العميل مدعوما ، فقد يكون الخطأ 415 تم إرجاعه إذا كان هناك محتوى غير مدعوم في نص الطلب. يشبه رمز الخطأ 415 من نوع الوسائط غير المدعوم رمز الحالة 406 غير مقبول. الفرق هو أن رمز الخطأ 406 غير المقبول لا يرجع إلى المحتوى الموجود في الرأس أو الترميز ، بل هو بسبب القيمة التي تم تعيينها داخل رأس HTTP. إن التأكد من أن الخادم يمكنه معالجة التنسيق المحدد إلى جانب إرسال الطلب باستخدام النموذج الصحيح سيتجنب حدوث رمز حالة خطأ 415 من نوع الوسائط غير المدعوم. See RFC7231، القسم 6.5.13
لمزيد من المعلومات.
416: نطاق غير قابل للتلبية
كما هو مذكور مع رمز حالة الطلب الجزئي 206 ، من الممكن للعملاء / المتصفحات طلب استجابة جزئية من الخدمةr ، سواء كان ذلك iجزء معين من ملف أو فيديو على سبيل المثال. يستخدم العملاء والخوادم ما يسمى بطلبات النطاق ل تنفيذ هذه الطلبات. ومع ذلك ، إذا كان الخادم يفعل ذلك لا تدعم هذه الأنواع من الطلبات ، وسوف تقوم ببساطة بإرجاع resou بالكاملrce جنبا إلى جنب مع استجابة 200 موافق. إذا كان الخادم يدعم طلبات النطاق،ر هو حيث 416 طلب جزئي خطأ رمز الحالة يدخل الصورة ويعيد ما يطلبه العميل. في حالة دعم الخادم لطلبات النطاق، ولكن خادم doeق لا أتفق مع طلب تلقى لأنه لا لا تقع ضمن النطاق أو ربما أبعد من ذلك النطاق المحدد، النطاق 416 غير قابل للتلبية خطأ سيتم إرجاع رمز الحالة. Sه RFC7233، القسم 4.4 لمزيد من المعلومات.
417: فشل التوقع
يمكن للعملاء استخدام رأس “توقع”
للإشارة إلى أنه يتوقع سلوكا محددا من الخادم. كما هو موضح في رمز حالة 100 Continue ، يمكن للعملاء التحقق من الخادم إذا كان سيقبل طلبا. إذا حدث ذلك ، فسيستجيب الخادم برمز حالة 100 Continue. إذا لم يكن الأمر كذلك ، رهو 417 فشل التوقع خطأ رمز الحالة يشير ذلك الخادم هل لا فهم توقع راس أو دعمه ، وبالتالي يمكنهلا معالجة الكلينt طلب. لمزيد من المعلومات حول رمز الخطأ 417 Expectation Failed، راجع RFC7231، القسم 6.5.14
418-42
0
: غير معين
أخطاء sرموز tatus 418-421 غير معينة حاليا ، ومع ذلك ، رمز الحالة 418 أنا يتم استخدام إبريق الشاي الصغير في بعض الحالات. تم إنشاؤها كمزحة كذبة أبريل ، وقد اكتسبت بعض الجر وهي تستخدم أحيانا كمزحة أو بيضة عيد الفصح ولا تستخدم للأغراض اليومية الفعلية. معظم المتصفحات تتجاهله لأنه ليس رمز حالة رسمي. واحد آخر في هذه الفئة هو رمز حالة الخطأ 420 Enhance Your Calm الذي كان التي قدمها تويتر. ومن is a n error code الذي يخبر العملاء أنهم are يجري معدل محدود ، which هو قيد على عدد الطلبات التي يمكنهم تقديمها خلال فترة زمنية محددة. منذ عام 1989 ، سينشر محرر RFC طلبات التعليقات الأكثر فكاهة. ويكيبيديا لديها متهدمة كاملة
من RFCs كذبة أبريل أكثر فكاهة.
421: طلب موجه بشكل خاطئ
تم تقديمه باستخدام بروتوكول HTTP / 2 ، ال 421 طلب موجه بشكل خاطئ خطأ رمز الحالة يعني أن الخادم recطلب كان لا مخصص لهذا الخادم المحدد ولا يمكن الاستجابة بشكل صحيح. يمكن أن يحدث هذا إذا تم تعيين DNS (نظام أسماء النطاقات) على عنوان IP خاطئ. العملاء مطلوب منهم تشمل مضيف رأس في الطلب. يمكن أن يحدث هذا أيضا مع المواقع التي تحتوي على موقع واحد طبقة المقابس الآمنة (SSL شهادة من نطاقات متعددة. يمكن أن يحدث هذا بسببn مشكلة مع مزود الاستضافة و / أو متصفح معين مستخدم ، لذلك قد يتطلب الأمر قدرا كبيرا من العمل لفهم أين تكمن المشكلة حقا. إذا كان الخادم يعرف أنه لم يتم تكوين مجال على request، وسوف يستجيب مع طلب 421 موجه بشكل خاطئ الاستجابة للخطأ. Sه RFC7540، القسم 9.1.2 لمزيد من المعلومات.
422:
كيان
غير قابل للمعالجة
أ 422 غير قابل للمعالجة كيان خطأ رمز الحالة يشير مشكلة مع محتويات بناء جملة الطلب. ال ترتيب الطلب تم فهمه من قبل الخادملكن ال الحقول داخل الطلب غير صالحة أو لا لا مطابقة ما يتوقعه الخادم. مثل معالجة 102 و 207 متعدد-رموز الحالة ، و 422 غير قابل للمعالجة كيان خطأ الرمز هو جزء من بروتوكول WebDAV وغالبا ما تستخدم مع خدمات الويب / واجهات برمجة التطبيقات. وعموما، فإن 400 طلب غير صحيح هو الاستجابة الموصى بها ، ولكن إذا كان WebDAV مدعوما ، ثم tهو 422 غير قابل للمعالجة كيان يجب استخدامها. Sه RFC4918، القسم 11.2 لمزيد من المعلومات.
423: مغلق
مثل رمز حالة الكيان غير القابل للمعالجة 422 ، الخطأ 423 مؤمن رمز الحالة هو أيضا جزء من بروتوكول WebDAV. يشير رمز الحالة 423 Locked إلى أن filه، مورد، أو مباشرة، على سبيل المثال، لا يمكن تحريرها. الغرض منه هو تجنب قيام العديد من المستخدمين بتحديث ملف أو مورد وما إلى ذلك في وقت واحد. يمكن بعد ذلك إلغاء قفل هذه الموارد للتحرير ، wالدجاجة ضرورية. لمزيد من المعلومات حول رمز الخطأ 423 مقفل، راجع RFC4918، القسم 11.3
424: فشل التبعية
رمز حالة آخر مدعوم من WebDav البروتوكول؛ التبعية الفاشلة 424 يشير رمز حالة الخطأ إلى فشل الطلب من العميل بسبب الاعتماد على طلب آخر فشل أيضا. يستخدم WebDAV طريقة المعروف باسم
PROPPATCH
لتحديث بعض خصائص resource. ل تشير إلى ما إذا كان قد تم تحديث مورد بنجاح أم لا، يستخدم WebDAV استجابات رمز حالة HTTP القياسية. بالإضافة إلى ذلك، يتم استخدام رمز حالة التبعية الفاشلة 424 فقط في الحالة التي تحتوي فيها الاستجابة في نص HTTP على 207 Multi-Stاستجابة atus. So ، إذا تم استخدام PROPPATCH
وفشل المورد في التحديث ، فسيرسل رمز حالة 4xx يشير إلى هناك خطأ في تحديث المورد ، وسيتم أيضا إرسال رمز الخطأ 424 Failed Dependency مع الطلبات الأخرى التي تعتمد على نجاح هذا التحديث ولكنه فشل. See
RFC4918، القسم 11.4
لمزيد من المعلومات.
425: مبكر جدا
ليس رمز حالة HTTP شائعا يتم استخدامه اليوم ، يتم استخدام رمز الاستجابة للخطأ 425 المبكر جدا في المواقف التي يتصل فيها عميل HTTP بعميل HTTPS. أثناء العملية ، قد يستغرق الأمر وقتا طويلا لإنشاء اتصال بين الخادم والعميل. يمكن أن تشكل هذه العملية مشكلة أمنية ، لذلك سيخبر الخادم العميل بإعادة محاولة الطلب حتى يتم الاتصال الآمن TLS (أمان طبقة النقل) صنع. في هذه الحالة، سيتم إرجاع رمز الحالة 425 المبكر جدا. لمزيد من المعلومات حول رمز الخطأ 425 المبكر جدا، راجع
RFC8470، القسم 5.2
426: الترقية مطلوبة
يشير رمز حالة الخطأ 426 “مطلوب ترقية” إلى العميل أنه يحتاج إلى استخدام بروتوكول أحدث من أجل إرسال الطلبات إلى الخادم. على سبيل المثال، قد يكون العميل يستخدم وإصدار أقدم من HTTP، مثل HTTP/1.0، ولكن الخادم يتطلب بروتوكول الإنترنت (HTTP)2.0. لن يقبل الخادم طلب ولكن سوف يستجيب مرة أخرى إلى client تبين البروتوكول أو البروتوكولات المقبولة. بمجرد ترقية العميل إلى البروتوكول (البروتوكولات) المطلوبة ، سيقبل الخادم الطلبات من العميل. لمزيد من المعلومات حول رمز الخطأ 426 الترقية المطلوبة، راجع RFC7231، القسم 6.5.15
427: غير معين
خطأ status code 427 غير معين حاليا.
428: الشرط المسبق مطلوب
يشير رمز حالة الخطأ 428 الشرط المسبق المطلوب إلى العميل إلى أن الطلب إلى الخادم يجب أن يكون طلبا مشروطا. كما ذكر في 304 رمز الحالة غير المعدل، أ يمكن للعميل إرسال طلب مشروط إلى الخادممثل إذا كان المباراة, إذا لم يكن هناك تطابق, إذا-عدلت-منذ, إذا-غير معدل-منذأو إذا كان المدى. ومع ذلك، هذه الطلبات المشروطة ليست مطلوب. إذا كانت مطلوبة من قبل الخادم ، فإن الخادم يشير هذا عن طريق الاستجابة باستخدام رمز الخطأ 428 الشرط المسبق المطلوب. هذا قليلا مماثل ل رمز الخطأ 412 فشل الشرط المسبق ولكن 412 فشل الشرط المسبق يتم إرجاع رمز الخطأ فقط إذا قام العميل بتضمين طلب شرطي في الرأس الذي هل لا match حالة المورد على الخادم‘s جنب. من خلال إخطار المستخدمين بأن الطلبات يجب أن تكون مشروطة بطبيعتها ، يضمن ذلك أن المستخدمين يعملون مع الملفات أو الموارد المناسبة و يساعد على منع المستخدمون من التغييرات التي يحتمل أن تحل محل. Sه RFC6585، القسم 3 لمزيد من المعلومات.
429: طلبات كثيرة جدا
تماما مثل اسم الخطأ يشير الرمز إلى أن رمز حالة الخطأ 429 Too Many Requests يعني أنه يتم تنفيذ الحد من المعدل ، وأن عميل تجاوز الحد الأقصى لكيفية العديد من الطلبات يمكن أن تجعل في فترة زمنية محددة. جنبا إلى جنب مع استجابة الخطأ 429 طلبات كثيرة جدا ، يجب أن يكون اشارت كم من الوقت للانتظار قبل بدء طلب جديد إلى الخادم، لكنها ليست كذلك سابقا مطلوب للقيام بذلك. لمزيد من المعلومات حول رمز الخطأ “طلبات كثيرة جدا”، راجع RFC6585، القسم 4
430: غير معين
رمز حالة الخطأ 430 غير معين حاليا ، ومع ذلك ، فقد اقترح في وقت واحد أن يكون رمز الخطأ 430 Will Block داخل بروتوكول HTTP / 1.1. وكان القصد من ذلك هو أن يكون بمثابة استجابة لما هو المعروف باسم خطوط الأنابيب. سمح ذلك للعملاء بإرسال طلبات متعددة، عبر اتصال TCP، بينما كان ينتظر الخادم لإعادة الإرسال. أناt لم تصل رسميا إلى المعيار حيث تم تحديث HTTP protocol إلى HTTP / 2.0 ولم يتم اعتماد دعم بطانة الأنابيب على نطاق واسع.
431 رؤوس الطلبات كبيرة جدا
يشير رمز حالة الخطأ 431 Request Headers Too Large إلى أن العميل أرسل رأسا request يتجاوز الحد المسموح به. خوادم الويب المختلفة لها حدود حجم مسموح بها مختلفة عندما يتعلق الأمر بالرؤوس. قد يكون هذا بسبب طلب رأس فردي كبير جدا أو بسبب الجمع بين كامل حجم الكل طلبات الرأس. في معظم الحالات ، يمكن أن يكون من السهل علاج ذلك ، لأنه يحدث عادة بسبب إرسال الكثير من ملفات تعريف الارتباط أو ملفات تعريف الارتباط الكبيرة جدا في حجم الملف. لمزيد من المعلومات حول رمز الخطأ 431 Request Headers Too Large، راجع RFC6585، القسم 5
432-450
:
غير معين
رموز حالة الخطأ من 432 إلى 450 غير معينة حاليا.
451:
غير متوفر لأسباب قانونية
خطأ sرمز تاتوس 451 غير متوفر لأسباب قانونية يشير يرفض الخادم عرض المحتوى المطلوب بسبب قانوني اسباب ويجب أن تتضمن أيضا سبب الخطأ في الاستجابة للمستخدم. قد تتضمن أسباب استخدام رمز حالة الخطأ 451 غير متوفر لأسباب قانونية الحكومات التي تفرض رقابة على محتوى معين، المحتوى الذي ينتهك قوانين حقوق الطبع والنشر، مثل قانون الألفية الجديدة لحقوق طبع ونشر المواد الرقمية (DMCA)، أو المحتوى الذي ينتهك القوانين أو أوامر المحكمة. ال 403 ممنوع و 404 لم يتم العثور على رموز حالة rror تستخدم أحيانا بدلا من رمز حالة الخطأ 451 ، ولكن رمز حالة الخطأ 451 يوفر المزيد من المعلومات أو الشرح في why الخطأ يحدث. عادة ما يكون المستخدمون قد حصلوا على جميع أنحاءe 451 خطأ من خلال تنفيذ الشبكات الافتراضية الخاصة للوصول إلى المحتوى. See RFC7725، القسم 3
لمزيد من المعلومات.
452-499: غير معين
رموز الخطأ 452-499 غير معينة حاليا.
5xx: خطأ في الخادم
مثل رموز الحالة 4xx ، تشير رموز الحالة 5xx إلى وجود خطأ ، ولكن الخطأ المعني ليس من المحتمل أن يكون بسبب اتصال سيئ أو المتصفح نفسه. تشير رموز الحالة 5xx إلى هناك طق مشكلة على مستوى الخادم ولا يمكن معالجة طلب من العميل. جنبا إلى جنب مع الخطأ ، يجب أن يستجيب الخادم مع شرح للخطأ، سواء كانت حالة مؤقتة أو دائمة، وكيف يمكن علاجها.
500: خطأ داخلي في الخادم
رمز حالة خطأ الخادم الداخلي 500 يعني ببساطة أن الخادم واجه مشكلة ولا يمكن معالجة الطلب. نموذجيا، يستخدم رمز خطأ الخادم الداخلي 500 أكثر كرمز خطأ خادم عام إذا كانت المشكلة الدقيقة لاتقع ضمن أي من رمز حالة خطأ خادم 5xx الآخر المواصفات. Tهو 500 رمز خطأ الخادم الداخلي هو على الارجح الأكثر استخداما من رموز تصنيف خطأ الخادم 5xx. راجع RFC7231، القسم 6.6
لمزيد من المعلومات.
501
:
لم يتم تنفيذه
A 501 لم يتم تنفيذه تحدث رموز حالة الخطأ عندما يقوم الخادم بذلك لا التعرف على طريقة الطلب ، وبالتالي ، لا يمكن سوقم بترحيل الطلب أو معالجته. ومن أناs مثل رمز حالة خطأ العميل 405 الأسلوب غير المسموح بهلكن أ 501 رمز حالة الخطأ لم يتم تنفيذه يمكن أشار أن طريقة الطلب من العميل صالحة، فقط غير مدعومة من قبل الخادم. حالة الخطأ 405 طريقة غير مسموح بها أشار أن الطريقة التي يطلبها العميل هي لا مدعم وينبغي لا لقد كان استخدام. رأى RFC7231، القسم 6.6.2 لمزيد من المعلومات.
502
:
بوابة سيئة
يعني رمز حالة الخطأ 502 Bad Gateway أن الخادم يعمل كوكيل وتلقى استجابة من خادم أصلي عاد غير صالح. ومن أناق ممكن ذلك أنابسبب وجود خادم محمل بشكل زائد ويمكن للعميل إعادة إرسال الطلب ، ولكن في معظم الحالات, انها أناs سبب ل مشكلة في خادم الويب أو CDN (شبكة توزيع المحتوى) يجلس بين العميل والخادم وقد استلزم زائد استكشاف الأخطاء وإصلاحها مع مزود الاستضافة لفهم سبب طرح الخطأ. رأى
RFC7231، القسم 6.6.3
لمزيد من المعلومات.
503
:
الخدمة غير متوفرة
يشير رمز حالة الخطأ 503 Service Unavailable إلى أن الخادم مثقل حاليا بالطلبات أو خارج الموارد ، وهو حاليا in الصيانة ، أو ربما في التطبيق الذي يحاولون الوصول إليه معطل ، ولا يستطيع الخادم إكمال الطلب بسبب الحالة الحالية. سيرى العملاء أحيانا رسالة مع رمز حالة الخطأ 503 Service Unavailable لإخبارهم بمحاولة الطلب مرة أخرى فيما بعد. ومع ذلك ، فإنه قد لا يقدم تفسيرا نهائيا لمتى أو كم من الوقت قد يستمر رمز حالة الخطأ غير المتوفر في خدمة th e 503. انظر RFC7231، القسم 6.6.4
للحصول على معلومات.
504: مهلة البوابة
مثل رمز حالة خطأ 502 Bad Gateway ، يتم استخدام رمز حالة خطأ 504 Gateway Timeout عندما يعمل الخادم كوكيل ولكنه سيستجيب باستخدام 504 Gateway Timeou t رمز حالة الخطأ إذا كان الرد منn يستغرق الخادم الأصلي وقتا طويلا جدا للاستجابة. يجب استخدام رمز حالة خطأ 502 Bad Gateway في الحالات التي تكون فيها الاستجابة غير صالحة أو لم يتم استلامها بواسطة الخادم الوكيل إطلاقًا. الرسالة جنبا إلى جنب مع 504 جاتeالطريقة التي قد تشير إليها المهلة ويوصي أن يحاول العميل إعادة إرسال الطلب. رأى RFC7231، القسم 6.6.5 لمزيد من المعلومات.
505: إصدار HTTP غير مدعوم
يعني رمز حالة الخطأ 505 HTTP Version غير مدعوم أن الخادم لا يدعم إصدار بروتوكول HTTP المستخدم في رسالة الطلب ، وبالتالي ،لا يمكن معالجة الطلب. جنبا إلى جنب مع إصدار HTTP 505 رمز حالة الخطأ غير معتمد ، يجب أن تتضمن الاستجابة من الخادم رسالة تشير إلى سبب عدم دعم بروتوكول HTTP المحدد والبروتوكولات المدعومة. راجع RFC7231، القسم
6.6.6 لمزيد من المعلومات.
506: البديل يتفاوض أيضا
البديل 506 يتفاوض أيضا هو رمز حالة HTTP تجريبي وليس جزءا من المعيار اليوم. يشير متغير 506 أيضا إلى وجود مشكلة في التكوين الداخلي مع الخادم بسبب قضايا التفاوض على المحتوى. يسمح التفاوض على المحتوى للعملاء بالإرسال تقبل الرؤوس المتعددة وتخبر الخادم بالتمثيل المحدد للمورد الذي يجب أن يعمل كما هو موضح في المتصفح. هذا يمكن أن يكون ل تقديم اللغة الصحيحة ، وشكل المستندt، وما إلى ذلك. على الرغم من أن البديل 506 يتفاوض أيضا على رمز حالة الخطأ في أ يتم استخدام الحالة التجريبية وليست رسميا جزءا من معيار HTTP ، في حالات نادرة. واجه بعض مستخدمي Google Playهذه المشكلة في الماضي عند محاولة تنزيل إصدارات متعددة من أحد التطبيقات ، مما تسبب في أن تحاول أجهزة IR باستمرار تنزيل التطبيق في عملية حلقة مغلقة. راجع RFC2295، القسم 8.1
لمزيد من المعلومات.
507: تخزين غير كاف
رمز حالة خادم تخزين غير كاف 507 هو أيضا جزء من بروتوكول WebDAV. رمز حالة خطأ التخزين غير الكافي 507 يشير إلى clien t that الطلب ، مثل PUT
أو POST
طلب ، كان كبيرا جدا في حجم الملف. يمكن أن يشير أيضا إلى أن الخادم يحتوي على نفدت مساحة التخزين مؤقتا. راجع RFC4981، القسم 11.5
لمزيد من المعلومات.
508: تم الكشف عن حلقة
تم اكتشاف الحلقة 508 ملقم رمز حالة الخطأ، مثل رمز الخطأ خادم التخزين غير الكافي 507، هو جزء من بروتوكول WebDAV. ضمن بروتوكول WebDAV ، انها أناs ممكن يمكن للعميل تقديم طلب إلى خادم لدليل كامل وإنشاء هدف بعضأين هذا الدليل نفسه ، مما يؤدي إلى حلقة طلب / استجابة لا نهائية. رمز حالة خطأ الخادم 508 Loop Detectestore. يشير أن الخادم انتهت طلب العميلتحديدا العمق: فيfعدم التناسق, لأن الحصةايه تحديد الطلب على النحو التالي مما أدى إلى طحلقة nfinite، والاتصال مرة أخرى على نفسها. رأى RFC5842، القسم 7.2 للمزيد معلومات.
509: غير معين
رمز حالة خطأ الخادم 509 غير معين حاليا.
510: غير ممتد
رمز حالة خطأ الخادم 510 غير الموسع موجود حاليا في الحالة المقترحة/التجريبية وليس جزءا من مواصفات رمز حالة HTTP القياسية. يشير 510 غير موسع إلى العميل إلى أن الطلب يتطلب طلب HTTP موسع. إذا استجاب الخادم برمز حالة خطأ الخادم 510 Not Extended ، فيجب أن يتضمن أيضا كيفية استخدام clيجب أن يكون ريمايدي طلبهم ، ولكن المواصفات هل لا صراحه حالة ذلك. هناك‘s ديباتي ما إذا كان رلهيقع hould تحت تصنيف خطأ خادم 5xx لأنه يمكن اعتباره خطأ عميل 4xx ، ولكن منذ ذلك الحين إنه من دواعي سروري ليس رسميا جزءا من المعيار ، فإنه أناق ليس relevنمل ونادرا ما تستخدم للاستخدام اليومي. رأى RFC2774، القسم 7 لمزيد من المعلومات.
511: مطلوب ترخيص الشبكة
رمز حالة خطأ الخادم المطلوب 511 Network Authorization الذي يتطلب من العميل مصادقة نفسه للوصول إلى شبكة. على سبيل المثال، قد يرى المستخدمون ذلك عند محاولة الاتصال بشبكة Wi-Fi عامة في نشاط تجاري ويجب على المستخدمين الموافقة على الشروط والأحكام الخاصة بهم قبل منحهم حق الوصول. جنبا إلى جنب مع تفويض الشبكة 511 المطلوبة استجابة لخطأ الخادم ، يجب أيضا توجيه المستخدمين إلى حيث يمكنهم تسجيل الدخول. راجع RFC6585، القسم 6
لمزيد من المعلومات.
512-599: غير معين
رموز حالة خطأ الخادم 512-599 غير معينة حاليا، ولكن قد تستخدم بعض الشركات أيا منها كرسائل خطأ خادم مخصصة للعملاء.
مراقبة
استجابات
رمز حالة HTTP
للاطلاع على قائمة برموز الحالة لعنوان URL معين بشكل مباشر، يمكنك التحقق من علامة التبويب أدوات مطوري البرامج ضمن التصفحr. إلى جانب مقاييس سرعة تحميل الصفحة ، يمكنك أيضا عرض أي استجابات للخادم ، إلى جانب جميع رموز حالة HTTP المرتبطة بها ، للتأكد من أن كل شيء على صفحتك يتم تحميله و تقديم صحيح.
للحصول على نهج مراقبة أكثر استباقية وتلقائية ، يمكن لحلول المراقبة الاحترافية من Dotcom-Monito r التأكد من أنه كلما واجه المستخدم رمز خطأ HTTP محددا ، يتم إعلامك بفرق r على الفور قس يمكنهم علاج المشكلة بسرعة. يمكنك أيضا استخدام ميزة الفلاتر لإزالتها رموز حالة HTTP فردية من المهام والتنبيهات والتقارير، لذلك يمكنك تجاهل أي رموز حالة HTTP غير ذات صلة باحتياجاتك المحددة.