| رمز حالة HTTP | معنى رمز الحالة |
|---|
| 100 | يجب على العميل الاستمرار في إرسال الطلبات. يتم استخدام هذا الرد المؤقت لإبلاغ العميل بأن جزءًا من طلبه قد استلمه الخادم ولم يتم رفضه بعد. يجب على العميل الاستمرار في إرسال بقية الطلب، أو تجاهل هذه الاستجابة إذا كان الطلب قد اكتمل بالفعل. يجب على الخادم إرسال الرد النهائي إلى العميل بعد اكتمال الطلب. |
| 101 | لقد فهم الخادم طلب العميل وسيقوم بإعلام العميل من خلال رأس رسالة الترقية لاستخدام بروتوكول مختلف لإكمال الطلب. بعد إرسال السطر الفارغ الأخير من هذه الاستجابة، سيتحول الخادم إلى البروتوكولات المحددة في رأس الترقية. ولا ينبغي اتخاذ مثل هذه التدابير إلا عندما يكون التحول إلى بروتوكول جديد أكثر فائدة. على سبيل المثال، يتمتع التبديل إلى إصدار HTTP جديد بمزايا مقارنة بالإصدار الأقدم، أو التبديل إلى بروتوكول متزامن في الوقت الفعلي لتقديم الموارد التي تستفيد من هذه الميزات. |
| 102 | رمز الحالة الممتد بواسطة WebDAV (RFC 2518) يشير إلى أن المعالجة ستستمر. |
| 200 | كان الطلب ناجحًا وسيتم إرجاع رؤوس الاستجابة أو نص البيانات المتوقع بواسطة الطلب مع هذه الاستجابة. |
| 201 | تم استيفاء الطلب، وتم إنشاء مورد جديد بناءً على احتياجات الطلب، وتم إرجاع URI الخاص به مع رأس الموقع. إذا لم يكن من الممكن إنشاء الموارد المطلوبة في الوقت المناسب، فيجب إرجاع "تم قبول 202". |
| 202 | قبل الخادم الطلب ولكنه لم يعالجه بعد. وكما قد يتم رفض الطلب، فقد يتم تنفيذه أو لا يتم تنفيذه في النهاية. في حالة العمليات غير المتزامنة، لا توجد طريقة أكثر ملاءمة من إرسال رمز الحالة هذا. الغرض من إرجاع استجابة رمز الحالة 202 هو السماح للخادم بقبول الطلبات من العمليات الأخرى (مثل العملية المستندة إلى الدُفعات والتي يتم تنفيذها مرة واحدة فقط يوميًا) دون الحاجة إلى إبقاء العميل متصلاً بالخادم حتى العملية الدفعية قد اكتمل. يجب أن تحتوي الاستجابة التي تقبل معالجة الطلب وترجع رمز الحالة 202 على بعض المعلومات في الكيان الذي تم إرجاعه مما يشير إلى الحالة الحالية للمعالجة، بالإضافة إلى مؤشر لمراقبة حالة المعالجة أو التنبؤ بالحالة حتى يتمكن المستخدم من تقدير ما إذا كانت العملية أم لا اكتمل. |
| 203 | لقد نجح الخادم في معالجة الطلب، ولكن المعلومات التعريفية لرأس الكيان التي تم إرجاعها ليست مجموعة محددة صالحة على الخادم الأصلي، ولكنها نسخة من جهة محلية أو خارجية. قد تكون المعلومات الحالية مجموعة فرعية أو مجموعة شاملة من الإصدار الأصلي. على سبيل المثال، قد يؤدي احتواء البيانات التعريفية لأحد الموارد إلى معرفة الخادم الأصلي للمعلومات الفائقة حول البيانات التعريفية. استخدام رمز الحالة هذا غير مطلوب وهو مناسب فقط إذا كانت الاستجابة ستعيد 200 OK بدون رمز الحالة هذا. |
| 204 | نجح الخادم في معالجة الطلب ولكنه لا يحتاج إلى إرجاع أي محتوى للكيان ويريد إرجاع معلومات التعريف المحدثة. قد تُرجع الاستجابة معلومات تعريفية جديدة أو محدثة في شكل رؤوس الكيانات. يجب أن تتوافق هذه الرؤوس، إذا كانت موجودة، مع المتغيرات المطلوبة. إذا كان العميل متصفحًا، فيجب أن يحتفظ متصفح المستخدم بالصفحة التي تم تقديم الطلب لها دون أي تغييرات في عرض المستند، حتى إذا كان يجب تطبيق معلومات تعريفية جديدة أو محدثة على نشاط متصفح المستخدم وفقًا لمواصفات المستندات المعروضة. نظرًا لأن الرد 204 محظور أن يحتوي على أي نص للرسالة، فإنه ينتهي دائمًا بالسطر الفارغ الأول بعد رأس الرسالة. |
| 205 | نجح الخادم في معالجة الطلب ولم يُرجع أي شيء. ولكن على عكس الاستجابة 204، فإن الاستجابة التي تعيد رمز الحالة هذا تتطلب من الطالب إعادة تعيين عرض المستند. تُستخدم هذه الاستجابة بشكل أساسي لإعادة ضبط النموذج فورًا بعد قبول إدخال المستخدم حتى يتمكن المستخدم من بدء إدخال آخر بسهولة. مثل الرد 204، يُحظر أن يحتوي هذا الرد على أي نص للرسالة وينتهي بالسطر الفارغ الأول بعد رأس الرسالة. |
| 206 | لقد نجح الخادم في معالجة جزء من طلب GET. تستخدم أدوات تنزيل HTTP مثل FlashGet أو Thunder هذا النوع من الاستجابة لاستئناف التنزيلات المتقطعة أو تقسيم مستند كبير إلى مقاطع تنزيل متعددة للتنزيل المتزامن. يجب أن يتضمن الطلب رأس نطاق للإشارة إلى نطاق المحتوى الذي يتوقعه العميل، وقد يتضمن نطاق If كشرط للطلب. يجب أن تتضمن الاستجابة حقول الرأس التالية: يتم استخدام نطاق المحتوى للإشارة إلى نطاق المحتوى الذي يتم إرجاعه في هذه الاستجابة؛ إذا كان تنزيلًا متعدد الأجزاء مع نطاقات متعددة الأجزاء/وحدات بايت من نوع المحتوى، فيجب أن يحتوي كل جزء متعدد الأجزاء على نطاق المحتوى يتم استخدام المجال للإشارة إلى نطاق محتوى هذه الفقرة. إذا تم تضمين طول المحتوى في الاستجابة، فيجب أن تتطابق قيمته مع العدد الفعلي للبايتات في نطاق المحتوى الذي يُرجعه. التاريخ ETag و/أو موقع المحتوى، إذا كان من المفترض أن يعرض نفس الطلب استجابة 200. Expires و/أو Cache-Control و/أو Vary، إذا كانت قيمتها مختلفة عن القيمة المقابلة للاستجابات السابقة الأخرى لنفس المتغير. إذا كان طلب الاستجابة هذا يستخدم التحقق من ذاكرة التخزين المؤقت القوية من If-Range، فيجب ألا تحتوي هذه الاستجابة على رؤوس كيانات أخرى؛ إذا كان طلب الاستجابة هذا يستخدم التحقق من ذاكرة التخزين المؤقت الضعيفة من If-Range، فيُمنع أن تحتوي هذه الاستجابة على رؤوس كيانات أخرى؛ وهذا يتجنب ويحل التناقضات بين محتوى الكيان المخزن مؤقتًا ومعلومات رأس الكيان المحدثة. بخلاف ذلك، يجب أن تحتوي هذه الاستجابة على كافة حقول رأس الكيان التي يجب إرجاعها في استجابة 200. إذا كانت رؤوس ETag أو Last-Modified غير متطابقة تمامًا، فيجب ألا تجمع ذاكرة التخزين المؤقت للعميل المحتوى الذي تم إرجاعه بواسطة الاستجابة 206 مع أي محتوى تم تخزينه مؤقتًا مسبقًا. يُحظر على أي ذاكرة تخزين مؤقت لا تدعم رؤوس Range وContent-Range تخزين المحتوى الذي يتم إرجاعه بواسطة الاستجابة 206 مؤقتًا. |
| 207 | رمز الحالة الممتد بواسطة WebDAV (RFC 2518) يعني أن نص الرسالة اللاحقة سيكون رسالة XML وقد يحتوي على سلسلة من رموز الاستجابة المستقلة اعتمادًا على عدد الطلبات الفرعية السابقة. |
| 300 | يحتوي المورد المطلوب على سلسلة من الاستجابات الاختيارية، كل منها بعنوان خاص بها ومعلومات تفاوض برنامج تشغيل المتصفح. يمكن للمستخدم أو المتصفح اختيار العنوان المفضل لإعادة التوجيه. ما لم يكن هذا طلب HEAD، يجب أن تتضمن الاستجابة كيانًا يحتوي على قائمة سمات الموارد والعناوين التي يمكن للمستخدم أو المتصفح من خلالها اختيار عنوان إعادة التوجيه الأكثر ملاءمة. يتم تحديد تنسيق هذا الكيان من خلال التنسيق المحدد بواسطة نوع المحتوى. قد يقوم المتصفح تلقائيًا باتخاذ الاختيار الأنسب بناءً على تنسيق الاستجابة وإمكانيات المتصفح الخاصة. وبطبيعة الحال، لا تحدد مواصفات RFC 2616 كيفية إجراء هذا الاختيار التلقائي. إذا كان لدى الخادم نفسه بالفعل خيار تعليقات مفضل، فيجب تحديد URI لهذه التعليقات في الموقع؛ وقد يستخدم المتصفح قيمة الموقع هذه كعنوان لإعادة التوجيه التلقائي. بالإضافة إلى ذلك، هذه الاستجابة قابلة للتخزين المؤقت ما لم يتم تحديد خلاف ذلك. |
| 301 | تم نقل المورد المطلوب بشكل دائم إلى موقع جديد، وأي مراجع مستقبلية لهذا المورد يجب أن تستخدم أحد معرفات URI العديدة التي يتم إرجاعها مع هذه الاستجابة. إذا كان ذلك ممكنًا، يجب على العملاء الذين يتمتعون بقدرات تحرير الارتباط تعديل العنوان المطلوب تلقائيًا إلى العنوان الذي تم إرجاعه من الخادم. ما لم يتم تحديد خلاف ذلك، فإن هذه الاستجابة قابلة للتخزين المؤقت أيضًا. يجب إرجاع عنوان URI الدائم الجديد في حقل الموقع للاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي كيان الاستجابة على رابط تشعبي لعنوان URI الجديد ووصف مختصر. إذا لم يكن هذا طلب GET أو HEAD، فإن المتصفح يحظر إعادة التوجيه التلقائي ما لم يتم تأكيده من قبل المستخدم، لأن شروط الطلب قد تتغير وفقًا لذلك. ملاحظة: بالنسبة لبعض المتصفحات التي تستخدم بروتوكول HTTP/1.0، عندما يحصل طلب POST الذي يرسلونه على استجابة 301، سيصبح طلب إعادة التوجيه اللاحق أسلوب GET. |
| 302 | يستجيب المورد المطلوب الآن بشكل مؤقت للطلبات الواردة من عنوان URI مختلف. ونظرًا لأن عمليات إعادة التوجيه هذه مؤقتة، فيجب على العميل الاستمرار في إرسال الطلبات المستقبلية إلى العنوان الأصلي. تكون هذه الاستجابة قابلة للتخزين المؤقت فقط إذا تم تحديدها في التحكم في ذاكرة التخزين المؤقت أو انتهاء الصلاحية. يجب إرجاع عنوان URI المؤقت الجديد في حقل الموقع للاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي كيان الاستجابة على رابط تشعبي لعنوان URI الجديد ووصف مختصر. إذا لم يكن هذا طلب GET أو HEAD، فإن المتصفح يحظر إعادة التوجيه التلقائي ما لم يتم تأكيده من قبل المستخدم، لأن شروط الطلب قد تتغير وفقًا لذلك. ملاحظة: على الرغم من أن مواصفات RFC 1945 وRFC 2068 لا تسمح للعميل بتغيير طريقة الطلب عند إعادة التوجيه، فإن العديد من المتصفحات الحالية تعتبر الاستجابة 302 بمثابة استجابة 303، وتستخدم طريقة GET للوصول إلى URI المحدد في الموقع، بغض النظر عن ذلك. طريقة الطلب الأصلي. تمت إضافة رموز الحالة 303 و307 لتوضيح الاستجابة التي يتوقعها الخادم من العميل. |
| 303 | يمكن العثور على الاستجابة للطلب الحالي في URI آخر، ويجب على العميل استخدام GET للوصول إلى هذا المورد. توجد هذه الطريقة في المقام الأول للسماح بإعادة توجيه إخراج طلب POST المنشط بالبرنامج النصي إلى مورد جديد. معرف الموارد المنتظم (URI) الجديد هذا ليس مرجعًا بديلاً للمورد الأصلي. في الوقت نفسه، يُحظر تخزين 303 استجابات مؤقتًا. بالطبع، قد يكون الطلب الثاني (إعادة التوجيه) مخبأً مؤقتًا. يجب إرجاع URI الجديد في حقل الموقع للاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي كيان الاستجابة على رابط تشعبي لعنوان URI الجديد ووصف مختصر. ملاحظة: العديد من متصفحات ما قبل HTTP/1.1 لا تفهم الحالة 303 بشكل صحيح. إذا كنت بحاجة إلى التفكير في التفاعل مع هذه المتصفحات، فيجب أن يكون رمز الحالة 302 كافيًا، لأن معظم المتصفحات تتعامل مع 302 استجابات تمامًا بالطريقة التي تتطلب المواصفات المذكورة أعلاه من العميل التعامل مع 303 استجابات. |
| 304 | إذا أرسل العميل طلب GET مشروطًا وتم السماح بالطلب، لكن محتوى المستند لم يتغير (منذ آخر وصول أو وفقًا لشروط الطلب)، فيجب على الخادم إرجاع رمز الحالة هذا. يُمنع الرد 304 من تضمين نص الرسالة، لذلك ينتهي دائمًا بالسطر الفارغ الأول بعد رأس الرسالة. يجب أن تحتوي الاستجابة على معلومات الرأس التالية: التاريخ، ما لم يكن لدى الخادم ساعة. إذا كانت الخوادم التي لا تحتوي على ساعات تلتزم أيضًا بهذه القواعد، فيمكن للخوادم الوكيلة والعملاء إضافة حقل التاريخ إلى رؤوس الاستجابة المستلمة بأنفسهم (كما هو محدد في RFC 2068)، وستعمل آلية التخزين المؤقت بشكل طبيعي. ETag و/أو Content-Location، إذا كان من المفترض أن يُرجع نفس الطلب استجابة 200. Expires و/أو Cache-Control و/أو Vary، إذا كانت قيمتها مختلفة عن القيمة المقابلة للاستجابات السابقة الأخرى لنفس المتغير. إذا كان طلب الاستجابة هذا يستخدم تحققًا قويًا من ذاكرة التخزين المؤقت، فيجب ألا تحتوي هذه الاستجابة على رؤوس كيانات أخرى؛ وإلا (على سبيل المثال، يستخدم طلب GET المشروط التحقق الضعيف من ذاكرة التخزين المؤقت)، يُحظر أن تحتوي هذه الاستجابة على رؤوس كيانات أخرى؛ وهذا يتجنب ويحل التناقضات بين ذاكرة التخزين المؤقت محتوى الكيان ومعلومات رأس الكيان المحدثة. إذا كانت الاستجابة 304 تشير إلى أن الكيان غير مخزن مؤقتًا حاليًا، فيجب أن يتجاهل نظام التخزين المؤقت الاستجابة ويكرر الطلب دون التقييد. إذا تم تلقي استجابة 304 تتطلب تحديثًا لإدخال ذاكرة التخزين المؤقت، فيجب على نظام ذاكرة التخزين المؤقت تحديث الإدخال بالكامل ليعكس قيم جميع الحقول التي تم تحديثها في الاستجابة. |
| 305 | يجب الوصول إلى المورد المطلوب من خلال الوكيل المحدد. سيتم تقديم معلومات URI الخاصة بالوكيل المحدد في حقل الموقع، ويحتاج المستلم إلى إرسال طلب منفصل بشكل متكرر للوصول إلى الموارد المقابلة من خلال هذا الوكيل. يمكن للخادم الأصلي فقط إنشاء استجابة 305. ملاحظة: لا يحدد RFC 2068 أن الاستجابة 305 تهدف إلى إعادة توجيه طلب واحد ولا يمكن إنشاؤها إلا بواسطة الخادم الأصلي. تجاهل هذه القيود يمكن أن يؤدي إلى عواقب وخيمة على السلامة. |
| 306 | في أحدث إصدار من المواصفات، لم يعد رمز الحالة 306 مستخدمًا. |
| 307 | يستجيب المورد المطلوب الآن بشكل مؤقت للطلبات الواردة من عنوان URI مختلف. ونظرًا لأن عمليات إعادة التوجيه هذه مؤقتة، فيجب على العميل الاستمرار في إرسال الطلبات المستقبلية إلى العنوان الأصلي. تكون هذه الاستجابة قابلة للتخزين المؤقت فقط إذا تم تحديدها في التحكم في ذاكرة التخزين المؤقت أو انتهاء الصلاحية. يجب إرجاع عنوان URI المؤقت الجديد في حقل الموقع للاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي كيان الاستجابة على رابط تشعبي لعنوان URI الجديد ووصف مختصر. نظرًا لأن بعض المتصفحات لا يمكنها التعرف على الاستجابة 307، يجب إضافة المعلومات الضرورية المذكورة أعلاه حتى يتمكن المستخدمون من فهم وتقديم طلبات الوصول إلى URI الجديد. إذا لم يكن هذا طلب GET أو HEAD، فإن المتصفح يحظر إعادة التوجيه التلقائي ما لم يتم تأكيده من قبل المستخدم، لأن شروط الطلب قد تتغير وفقًا لذلك. |
| 400 | 1. الدلالات غير صحيحة ولا يمكن للخادم فهم الطلب الحالي. يجب على العميل عدم إعادة إرسال هذا الطلب ما لم يتم تعديله. 2. معلمات الطلب غير صحيحة. |
| 401 | يتطلب الطلب الحالي مصادقة المستخدم. يجب أن تتضمن الاستجابة رأس WWW-Authenticate المناسب للمورد المطلوب الذي يطلب معلومات المستخدم. يمكن للعميل إرسال طلب بشكل متكرر يحتوي على معلومات رأس التفويض المناسبة. إذا كان الطلب الحالي يحتوي بالفعل على شهادات تفويض، فإن الاستجابة 401 تشير إلى أن التحقق من الخادم قد رفض تلك الشهادات. إذا كانت الاستجابة 401 تحتوي على نفس استعلام المصادقة مثل الاستجابة السابقة، وحاول المتصفح المصادقة مرة واحدة على الأقل، فيجب على المتصفح عرض معلومات الكيان المضمنة في الاستجابة للمستخدم، لأن معلومات الكيان هذه قد تحتوي على معلومات تشخيصية ذات صلة. انظر RFC 2617. |
| 402 | رمز الحالة هذا محجوز للاحتياجات المستقبلية المحتملة. |
| 403 | لقد فهم الخادم الطلب، لكنه رفض تنفيذه. على عكس الاستجابة 401، لا تقدم المصادقة أي مساعدة، ولا ينبغي إعادة تقديم الطلب. إذا لم يكن هذا طلبًا رئيسيًا وكان الخادم يريد أن يكون قادرًا على شرح سبب عدم إمكانية تنفيذ الطلب، فيجب وصف سبب الرفض في الكيان. بالطبع، يمكن للخادم أيضًا إرجاع استجابة 404 إذا كان لا يريد أن يحصل العميل على أي معلومات. |
| 404 | فشل الطلب. لم يتم العثور على المورد المطلوب على الخادم. لا توجد معلومات لإخبار المستخدم ما إذا كانت الحالة مؤقتة أم دائمة. إذا كان الخادم يعرف الموقف، فيجب عليه استخدام رمز الحالة 410 لإبلاغه بأن المورد القديم غير متاح بشكل دائم بسبب بعض مشكلات آلية التكوين الداخلي، ولا يوجد عنوان انتقال. يتم استخدام رمز الحالة 404 على نطاق واسع عندما لا يرغب الخادم في الكشف عن سبب رفض الطلب أو عدم توفر استجابة أخرى مناسبة. |
| 405 | لا يمكن استخدام طريقة الطلب المحددة في سطر الطلب لطلب المورد المقابل. يجب أن ترجع الاستجابة السماح بمعلومات الرأس للإشارة إلى قائمة أساليب الطلب التي يمكن للمورد الحالي قبولها. نظرًا لأن طريقتي PUT وDELETE ستقومان بكتابة الموارد على الخادم، فإن معظم خوادم الويب لا تدعم أو لا تسمح بطرق الطلب المذكورة أعلاه ضمن التكوين الافتراضي، وسيتم إرجاع خطأ 405 لمثل هذه الطلبات. |
| 406 | لا تفي خصائص محتوى المورد المطلوب بالشروط الواردة في رأس الطلب، لذلك لا يمكن إنشاء كيان الاستجابة. ما لم يكن هذا طلب HEAD، يجب أن تعرض الاستجابة كيانًا يحتوي على قائمة سمات الكيان والعناوين التي يمكن للمستخدم أو المتصفح اختيار الأنسب منها. يتم تحديد تنسيق الكيان حسب نوع الوسائط المحدد في رأس نوع المحتوى. يمكن للمتصفح أن يقوم باختياره الأفضل بناءً على التنسيق وإمكانياته. ومع ذلك، لا تحدد المواصفات أي معايير لإجراء مثل هذه التحديدات التلقائية. |
| 407 | يشبه استجابة 401، باستثناء أنه يجب على العميل المصادقة مع الخادم الوكيل. يجب أن يقوم الخادم الوكيل بإرجاع مصادقة الوكيل للاستعلام عن الهوية. يمكن للعميل إرجاع رأس تفويض الوكيل للتحقق. انظر RFC 2617. |
| 408 | الطلب منتهي المدة. لم يكمل العميل إرسال الطلب خلال الوقت الذي كان فيه الخادم مستعدًا للانتظار. ويمكن للعميل إعادة تقديم هذا الطلب في أي وقت دون إجراء أي تغييرات. |
| 409 | لا يمكن إكمال الطلب بسبب وجود تعارض مع الحالة الحالية للمورد المطلوب. يجب استخدام هذا الرمز فقط إذا كان من المعتقد أن المستخدم قادر على حل التعارض وإعادة إرسال طلب جديد. يجب أن تحتوي الاستجابة على معلومات كافية للمستخدم لاكتشاف مصدر التعارض. تحدث التعارضات عادةً أثناء معالجة طلبات PUT. على سبيل المثال، في بيئة تستخدم التحقق من الإصدار، إذا كانت معلومات الإصدار المرفقة بطلب تعديل لمورد معين مقدم بواسطة PUT تتعارض مع طلب سابق (طرف ثالث)، فيجب على الخادم إرجاع خطأ 409 في هذا الوقت. أبلغ المستخدم أنه لا يمكن إكمال الطلب. في الوقت الحالي، من المحتمل أن يحتوي كيان الاستجابة على مقارنة فرق بين الإصدارين المتعارضين، بحيث يمكن للمستخدم إعادة إرسال الإصدار الجديد بعد الدمج. |
| 410 | المورد المطلوب لم يعد متاحًا على الخادم وليس له أي عنوان إعادة توجيه معروف. وينبغي اعتبار مثل هذا الوضع دائما. إذا كان ذلك ممكنًا، يجب على العملاء الذين يتمتعون بإمكانيات تحرير الارتباط إزالة كافة المراجع إلى هذا العنوان بإذن المستخدم. إذا كان الخادم لا يعرف أو لا يستطيع تحديد ما إذا كانت الحالة دائمة أم لا، فيجب استخدام رمز الحالة 404. ما لم يُذكر خلاف ذلك، فإن هذه الاستجابة قابلة للتخزين المؤقت. الغرض من الاستجابة 410 هو بشكل أساسي مساعدة مسؤولي موقع الويب في الحفاظ على موقع الويب، وإعلام المستخدمين بأن المورد لم يعد متاحًا، ويأمل مالك الخادم أن يتم أيضًا حذف جميع الاتصالات عن بعد التي تشير إلى هذا المورد. يعد هذا النوع من الحوادث شائعًا بين الخدمات ذات القيمة المضافة ذات الوقت المحدود. وبالمثل، يتم استخدام الاستجابة 410 أيضًا لإعلام العميل بأن الموارد التي تنتمي في الأصل إلى فرد ما لم تعد متوفرة على موقع الخادم الحالي. بالطبع، الأمر متروك تمامًا لمالك الخادم فيما إذا كان يجب وضع علامة "410 Gone" على جميع الموارد غير المتاحة بشكل دائم، والمدة التي يحتاجها للاحتفاظ بهذه العلامة. |
| 411 | يرفض الخادم قبول الطلب دون تحديد رأس طول المحتوى. بعد إضافة رأس صالح لطول المحتوى يشير إلى طول نص رسالة الطلب، يمكن للعميل إرسال الطلب مرة أخرى. |
| 412 | فشل الخادم في تلبية واحد أو أكثر من المتطلبات الأساسية الواردة في حقول رأس الطلب عند التحقق من صحتها. يسمح رمز الحالة هذا للعميل بتعيين شروط مسبقة في معلومات تعريف الطلب (بيانات حقل رأس الطلب) عند استرداد المورد، وبالتالي منع تطبيق أسلوب الطلب على المورد بخلاف ما يتوقعه. |
| 413 | يرفض الخادم معالجة الطلب الحالي لأن بيانات الكيان التي أرسلها الطلب أكبر من رغبة الخادم أو قدرته على التعامل معها. في هذه الحالة، يمكن للخادم إغلاق الاتصال لمنع العميل من الاستمرار في إرسال هذا الطلب. إذا كان الموقف مؤقتًا، فيجب على الخادم إرجاع رأس الاستجابة "إعادة المحاولة بعد" لإعلام العميل بالمدة التي يمكنه المحاولة مرة أخرى. |
| 414 | عنوان URI المطلوب أطول مما يستطيع الخادم تفسيره، لذلك يرفض الخادم خدمة الطلب. وهذا أمر نادر نسبيًا. تتضمن المواقف الشائعة: إرسال النموذج الذي يجب أن يستخدم أسلوب POST يصبح أسلوب GET، مما يؤدي إلى أن تكون سلسلة الاستعلام (سلسلة الاستعلام) طويلة جدًا. إعادة توجيه URI "الثقب الأسود"، على سبيل المثال، تستخدم كل عملية إعادة توجيه عنوان URI القديم كجزء من URI الجديد، مما يتسبب في أن يكون URI طويلًا جدًا بعد عدة عمليات إعادة توجيه. يحاول العميل مهاجمة الخادم من خلال استغلال ثغرة أمنية موجودة في بعض الخوادم. يستخدم هذا النوع من الخوادم مخزنًا مؤقتًا ثابت الطول لقراءة أو تشغيل URI المطلوب، وعندما تتجاوز المعلمات بعد GET قيمة معينة، قد يحدث تجاوز في المخزن المؤقت، مما يؤدي إلى تنفيذ تعليمات برمجية عشوائية [1]. يجب أن تقوم الخوادم التي لا تحتوي على مثل هذه الثغرات الأمنية بإرجاع رمز الحالة 414. |
| 415 | بالنسبة للطريقة المطلوبة حاليًا والمورد المطلوب، فإن الكيان المقدم في الطلب ليس بتنسيق يدعمه الخادم، لذلك يتم رفض الطلب. |
| 416 | إذا كان الطلب يحتوي على رأس طلب النطاق، ولم يتطابق أي نطاق بيانات محدد في النطاق مع النطاق المتاح للمورد الحالي، ولم يتم تحديد رأس طلب If-Range في الطلب، فيجب على الخادم إرجاع حالة 416 شفرة. إذا كان النطاق يستخدم نطاق بايت، فإن هذا الموقف يعني أن موضع البايت الأول لجميع نطاقات البيانات المحددة في الطلب يتجاوز طول المورد الحالي. يجب أن يتضمن الخادم أيضًا رأس كيان Content-Range للإشارة إلى طول المورد الحالي أثناء إرجاع رمز الحالة 416. يُحظر أيضًا على هذه الاستجابة استخدام أجزاء متعددة/وحدات بايت كنوع المحتوى الخاص بها. |
| 417 | لا يمكن للخادم تلبية المحتوى المتوقع المحدد في رأس الطلب المتوقع، أو أن الخادم هو خادم وكيل ولديه دليل واضح على عدم إمكانية تلبية محتوى المتوقع على العقدة التالية في المسار الحالي. |
| 421 | يتجاوز عدد الاتصالات بالخادم من عنوان IP الخاص بالعميل الحالي الحد الأقصى للنطاق المسموح به للخادم. عادةً ما يشير عنوان IP هنا إلى عنوان العميل الذي يظهر من الخادم (مثل بوابة المستخدم أو عنوان الخادم الوكيل). في هذه الحالة، قد يشمل عدد الاتصالات أكثر من مستخدم نهائي. |
| 422 | يتجاوز عدد الاتصالات بالخادم من عنوان IP الخاص بالعميل الحالي الحد الأقصى للنطاق المسموح به للخادم. عادةً ما يشير عنوان IP هنا إلى عنوان العميل الذي يظهر من الخادم (مثل بوابة المستخدم أو عنوان الخادم الوكيل). في هذه الحالة، قد يشمل عدد الاتصالات أكثر من مستخدم نهائي. |
| 422 | الطلب منسق بشكل جيد، ولكن لا يمكن الرد عليه بسبب وجود أخطاء لفظية. (RFC 4918 WebDAV) 423 مغلق، المورد الحالي مغلق. (RFC 4918 WebDAV) |
| 424 | فشل الطلب الحالي بسبب خطأ في طلب سابق، مثل PROPPATCH. (RFC 4918 WebDAV) |
| 425 | تم تحديده في مسودة مجموعات WebDav المتقدمة، ولكنه لا يظهر في "بروتوكول تجميع تسلسل WebDAV" (RFC 3658). |
| 426 | يجب على العملاء التبديل إلى TLS/1.0. (RFC 2817) |
| 449 | يشير الموسع بواسطة Microsoft إلى أنه يجب إعادة محاولة الطلبات بعد تنفيذ الإجراءات المناسبة. |
| 500 | واجه الخادم حالة غير متوقعة منعته من إكمال معالجة الطلب. بشكل عام، ستحدث هذه المشكلة عند وجود خطأ في كود برنامج الخادم. |
| 501 | لا يدعم الخادم ميزة مطلوبة بواسطة الطلب الحالي. عندما لا يتعرف الخادم على الطريقة المطلوبة ولا يمكنه دعم طلبه لأي مورد. |
| 502 | تلقى خادم يعمل كبوابة أو وكيل استجابة غير صالحة من خادم رئيسي أثناء محاولة تنفيذ الطلب. |
| 503 | بسبب الصيانة المؤقتة للخادم أو التحميل الزائد، فإن الخادم غير قادر حاليًا على معالجة الطلبات. هذه الحالة مؤقتة وسيتم استعادتها بعد فترة من الزمن. إذا كان من الممكن توقع وقت التأخير، فيمكن أن تتضمن الاستجابة رأس "إعادة المحاولة بعد" للإشارة إلى وقت التأخير. إذا لم يتم تقديم رسالة إعادة المحاولة هذه، فيجب على العميل التعامل معها بنفس الطريقة التي يتعامل بها مع الاستجابة 500. ملحوظة: وجود رمز الحالة 503 لا يعني أن الخادم يجب أن يستخدمه عند التحميل الزائد. ترغب بعض الخوادم ببساطة في رفض الاتصالات من العملاء. |
| 504 | عندما يحاول خادم يعمل كبوابة أو وكيل تنفيذ طلب، فإنه يفشل في تلقي استجابة في الوقت المناسب من الخادم الرئيسي (الخادم المحدد بواسطة URI، مثل HTTP، وFTP، وLDAP) أو الخادم المساعد (مثل DNS ). ملاحظة: ستعرض بعض الخوادم الوكيلة خطأ 400 أو 500 عند انتهاء مهلة استعلام DNS. |
| 505 | لا يدعم الخادم، أو يرفض دعم، إصدار HTTP المستخدم في الطلب. وهذا يعني أن الخادم غير قادر أو غير راغب في استخدام نفس الإصدار مثل العميل. يجب أن تحتوي الاستجابة على كيان يصف سبب عدم دعم الإصدار والبروتوكولات التي يدعمها الخادم. |
| 506 | يشير الموسع بواسطة بروتوكول تفاوض المحتوى الشفاف (RFC 2295)، إلى أن الخادم به خطأ في التكوين الداخلي: تم تكوين مورد وسيطة التفاوض المطلوب لاستخدام نفسه في مفاوضات المحتوى الشفاف، وبالتالي فهو ليس محور تركيز مناسب في عملية التفاوض. |
| 507 | لا يمكن للخادم تخزين المحتوى اللازم لإكمال الطلب. تعتبر هذه الحالة مؤقتة. WebDAV (RFC 4918) |
| 509 | لقد وصل الخادم إلى حد النطاق الترددي الخاص به. هذا ليس رمز الحالة الرسمي، ولكنه لا يزال يستخدم على نطاق واسع. |
| 510 | الاستراتيجيات المطلوبة للحصول على الموارد لم يتم استيفائها بعد. (RFC 2774) |