| كود حالة HTTP | معنى رمز الحالة |
|---|
| 100 | يجب على الجانب client الاستمرار في إرسال الطلبات. تستخدم هذه الاستجابة المؤقتة لتخبر الجانب client بأن بعض طلباته قد تم استقبالها من الخادم وليس قد تم رفضها. يجب على الجانب client الاستمرار في إرسال البقية من الطلب، أو تجاهل الاستجابة إذا تم إكمال الطلب. يجب على الخادم إرسال استجابة نهائية إلى الجانب client بعد إكمال الطلب. |
| 101 | فهم الخادم طلب العميل وسيعلم الجانب العملي من خلال عنوان الرأس Upgrade لاستخدام بروتوكول مختلف لإنهاء الطلب. بعد إرسال السطر الفارغ الأخير في الرد، سيبدأ الخادم في التبديل إلى تلك البروتوكولات المحددة في عنوان الرأس Upgrade. يجب اتخاذ مثل هذه الإجراءات فقط عندما يكون انتقال إلى بروتوكول جديد أكثر فائدة. على سبيل المثال، انتقال إلى إصدار جديد من HTTP له مزايا على الإصدار القديم، أو انتقال إلى HTTP الحقيقي-وقت وسلسلة التواصل المتزامنة لتسليم موارد تستفيد من هذه الميزات. |
| 102 | تمدد رمز الحالة من قبل WebDAV (RFC 2518) يشير إلى أن عملية المعالجة ستستمر. |
| 200. | تم الطلب بنجاح، ويتم العودة بالعناوين أو أجسام البيانات المطلوبة مع الرد. |
| 201 | تم إكمال الطلب، وقد تم إنشاء مورد جديد بناءً على متطلبات الطلب، وقد تم العودة بـ URI الخاص به مع عنوان الرأس Location. إذا لم يتمكن المورد المطلوب من إنشائه في الوقت المحدد،'202 'Accepted' يجب أن يتم العودة. |
| 202 | تم قبول الطلب من قبل الخادم، ولكن لم يتم معالجته بعد. تمامًا مثل أنه قد يتم رفضه، قد يتم تنفيذ الطلب أو لا يتم تنفيذه في النهاية. في حالة العمليات غير المتزامنة، لا يوجد طريقة أكثر راحة لفعل ذلك من إرسال هذا رمز الحالة. يجب أن يكون الغرض من العودة بـ 202 استجابة رمز الحالة للسماح للخادم باستقبال طلبات من عمليات أخرى (مثل البatch-عملية قاعدة تتم مرة واحدة في اليوم) دون الحاجة إلى الحفاظ على الاتصال بين الجانب العملي للعميل مع الخادم حتى اكتمال عملية البatch. في استجابة لقبول طلب معالجة والعودة بـ 202 الرمز، يجب أن يحتوي الكيان المعد للإرجاع على بعض المعلومات تشير إلى حالة العمل الحالية، بالإضافة إلى مرجع إلى مراقب حالة العمل أو توقع الحالة، حتى يتمكن المستخدم من تقدير ما إذا كان العمل قد اكتمل. |
| 203 | نجح الخادم في معالجة الطلب، ولكن المعلومات التوقيتات المتعلقة برأس الكيان التي تم إرجاعها ليست مجموعة محددة صحيحة على الخادم الأصلي، ولكنها محلية أو ثالثة-نسخة الجانب الآخر. قد تكون المعلومات الحالية فرعية أو مجموعة فرعية من النسخة الأصلية. على سبيل المثال، قد تسبب معلومات التوقيتات تحتوي على موارد أن يعرف الخادم الأصلي التوقيتات الرئيسية. ليس من الضروري استخدام هذا الرمز، ويكون مناسبًا فقط إذا كان الاستجابة تعيد 200 بدون هذا الرمز. |
| 204 | نجح الخادم في معالجة الطلب، ولكن لا يحتاج إلى إعادة تزويد أي محتوى مادي، ويود إعادة تزويد معلومات التوقيتات المحدثة. قد تكون الاستجابة في شكل رأس الكيان، عودة معلومات التوقيتات الجديدة أو المحدثة. إذا كانت هذه معلومات الرأس موجودة، يجب أن تتوافق مع المتغير المطلوب. إذا كان الجانب العميل هو المتصفح، فإن المتصفح المستخدم يجب أن يحافظ على الصفحة التي أرسل الطلب دون أية تغييرات في عرض الوثيقة، حتى لو كان يجب تطبيق المعلومات التوقيتات الجديدة أو المحدثة على الوثيقة في عرض المتصفح النشط للمستخدم. 204 يمنع الاستجابة من تضمين أي جسم رسالة، إنها تنتهي دائمًا بعد أول سطر فارغ بعد العنوان. |
| 205 | نجح الخادم في معالجة الطلب ولم يعد أي شيء. ولكن على عكس 204 الاستجابة، الاستجابة التي تعيد هذا رمز الحالة تتطلب من طلب العميل إعادة تعيين عرض الوثيقة. تستخدم هذه الاستجابة بشكل رئيسي لإعادة تعيين النموذج فور تقديم إدخال المستخدم حتى يتمكن المستخدم من بدء إدخال آخر بسهولة. مثل 204 الرد، فإن هذا الرد ممنوع أيضًا من إضافة أي جسم رسالة ويختم بعد أول سطر فارغ بعد الرؤوس. |
| 206 | تم معالجة جزء من طلب GET من قبل الخادم بنجاح. أدوات تنزيل HTTP مثل FlashGet أو Xunlei تستخدم هذا النوع من الرد لتحقيق استئناف نقطة انقطاع أو تقسيم وثيقة كبيرة إلى أجزاء تنزيل متعددة للتنزيل في نفس الوقت. يجب أن يحتوي الطلب على عنوان الرمز Range لتوضيح نطاق المحتوى الذي يريده الجانب客户端، وقد يحتوي أيضًا على If-Condition. يجب أن يحتوي الرد على العناوين التالية: Content-Range لتوضيح نطاق المحتوى المقدم في هذا الرد؛ إذا كان متعدد-تحميل الجزء المعدد مع Content-نوع multipart/byteranges، يجب أن يحتوي كل جزء متعدد على Content-حقل Range لتوضيح نطاق المحتوى لهذا الجزء. إذا كان الرد يحتوي على Content-Length، فإن قيمته يجب أن تطابق عدد البايتات الفعلي في نطاق المحتوى الذي يقدمه. تاريخ ETag و/أو Content-Location، إذا كان نفس الطلب يجب أن يرجع بهذا العنوان. 2رد 00. Expires، Cache-التحكم، وأيضاً/أو Vary، إذا كان قيمته قد تختلف عن القيمة الم correspondng إلى إجابات أخرى على نفس المتغير قبل ذلك. إذا كان هذا الرد يستخدم If-تأكيد Range قوي، فإن هذا الرد لا يجب أن يحتوي على أي عناوين الكيان الأخرى؛ إذا كان هذا الرد يستخدم If-تأكيد Range 弱، فإن هذا الرد لا يجب أن يحتوي على أي عناوين الكيان الأخرى؛ هذا يمنع عدم التساوي بين محتوى الكيان المخزن والمعلومات الرؤوسة المحدثة للكيان. وإلا، يجب أن يحتوي هذا الرد على جميع عناوين رؤوس الكيان التي يجب إرجاعها في 2الرد 00. إذا كان ETag أو Last-وعدادات Modified غير مطابقة تمامًا، يجب على المخزن الجانبي للمستخدم منع دمج المحتوى المقدم في 206 الرد مع أي محتوى مخزن مسبقًا. أي مخزن لا يدعم عنوان الرمز Range و-يمنع عنوان الرمز Range من تخزين المحتوى المقدم من قبل 206 . رد. |
| 207 | كود حالة تم تعديله من قبل WebDAV (RFC 2518) يمثل أن جسم الرسالة التالية سيكون رسالة XML، وقد يحتوي على سلسلة من رموز الاستجابة المستقلة بناءً على عدد المراتب السابقة-طلبات. |
| 300 | المورد المطلوب يحتوي على نطاق من خيارات التعليقات، كل منها يحتوي على عنوان محدد الخاص به ومتطلبات المتصفح-المعلومات. يمكن للمستخدم أو المتصفح اختيار عنوان تفضيلي للتحويل. ما لم يكن هذا طلب HEAD، يجب أن يحتوي الجسم المستجيب على جسم يحتوي على قائمة بالصفات والعناوين للمورد التي يمكن للمستخدم أو المتصفح اختيار عنوان التحويل الأنسب منها. يتم تحديد تنسيق هذا الجسم بتنسيق تم تحديده من قبل محتوى-نوع. قد يقرر المتصفح تلقائيًا الخيار الأنسب بناءً على تنسيق الاستجابة وقدرات المتصفح الخاصة. بالطبع، المفاوضة الدفع المحركة 2616 التعريف كيف يجب تنفيذ هذا التحديد التلقائي. إذا كان الخادم نفسه لديه اختيار تفضيلي للتعليقات، يجب تحديد URI للتعليقات في Location؛ قد يستخدم المتصفح هذه قيمة Location كعنوان للتحويل التلقائي. بالإضافة إلى ذلك، ما لم يُحدد خلاف ذلك، فإن الاستجابة قابلة للتخزين أيضًا. |
| 301 | المورد المطلوب قد تم نقلها إلى موقع جديد دائمًا، ويجب استخدام أحد عدة URIs المقدمة بهذه الاستجابة لأي مرجع مستقبلي لهذا المورد. إذا كان ذلك ممكنًا، يجب على الجانب التابع للعميل مع قدرات تحرير الروابط تغيير عنوان الطلب تلقائيًا إلى العنوان المقدم من الخادم. ما لم يُحدد خلاف ذلك، فإن هذه الاستجابة قابلة للتخزين أيضًا. يجب رد URI الدائم الجديد في حقل Location من الاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي الجسم المستجيب على رابط إلى URI الجديد ووصف قصير. إذا لم يكن هذا طلب GET أو HEAD، يُمنع المتصفح من التحويل التلقائي إلا إذا تم تأكيده من قبل المستخدم، لأن شروط الطلب قد تتغير نتيجة لذلك. ملاحظة: لبعض المتصفحات التي تستخدم بروتوكول HTTP، لا يحدد/1.0 البروتوكول، عندما يرسلون طلب POST ويحصلون على 301 الاستجابة، سيكون الطلب التوجيهي التالي GET. |
| 302 | ال مورد المطلوب الآن يستجيب مؤقتًا للطلب من URI آخر. منذ أن تكون هذه التوجيهات مؤقتة، يجب على الجانب العميل مواصلة إرسال طلبات المستقبل إلى العنوان الأصلي. يمكن تخزين هذه الاستجابة فقط إذا تم تحديد Cache-التحكم أو Expires. يجب إعادة توجيه URI الجديد في حقل Location من الاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي جسم الاستجابة على رابط إلى URI الجديد ووصف مختصر. إذا لم يكن هذا طلب GET أو HEAD، يحظر المتصفح التوجيه التلقائي إلا إذا تم تأكيده من قبل المستخدم، لأن ظروف الطلب قد تتغير نتيجة لذلك. ملاحظة: على الرغم من أن RFC 1945 والRFC 2068 التعليمات لا تسمح للجانب العميل بتغيير طريقة الطلب عند التوجيه، تعامل العديد من المتصفحات الحالية 302 الاستجابة ك 303 الاستجابة والاستخدام GET للوصول إلى URI المحدد في Location، تجاهل طريقة الطلب الأصلية. كودات الحالة 303 و 307 بإضافة وضوح ما يتوقعه الخادم من الجانب العميل. |
| 303 | يمكن العثور على استجابة الطلب الحالي على URI آخر، ويجب على الجانب العميل الحصول على الوصول إلى ذلك المورد باستخدام GET. يوجد هذا الأسلوب بشكل رئيسي لسماح-تم تفعيل إعادة توجيه مخرجات طلب POST إلى مورد جديد. هذا URI الجديد ليس بديلاً للمرجع الأصلي. أيضًا، 303 الردود يمنع من التخزين المؤقت. بالطبع، قد يتم تخزين الطلب الثاني (إعادة توجيه). يجب رد URI الجديد في حقل Location من الرد. ما لم يكن هذا طلب HEAD، يجب أن يحتوي كيان الرد على رابط إلى URI الجديد ووصف قصير. ملاحظة: العديد من المتصفحات قبل HTTP/1.1 لا يفهم 303 الوضع بشكل صحيح. إذا كنت بحاجة إلى النظر في التفاعل مع هذه المتصفحات، فإن 302 الرقم التعريفي يجب أن يكون كافيًا، لأن معظم المتصفحات تعالج 302 الردود بالضبط كما تتطلب هذه التوجيهات الجانب المستفيد التعامل معها 303 الردود. |
| 304 | إذا أرسل الجانب العملي طلب الحصول على بيانات تحت شرط وتم السماح بهذا الطلب، ولم يتغير محتوى المستند (منذ الزيارة الأخيرة أو وفقًا لشروط الطلب)، يجب على الخادم رد هذا الرقم التعريفي. 304 يمنع الرد من إضافة جسور الرسائل، لذا يجب أن ينتهي دائمًا بعد الأولى بعد رأس الرد. يجب أن يحتوي الرد على معلومات رأس التغطية التالية: التاريخ، ما لم يكن لدي هذا الخادم ساعة.
إذا اتبعت الخادمة بدون ساعة هذه القواعد أيضًا، فإن خادم الوكيل والجهة المستفيدة يمكنهما إضافة حقل التاريخ إلى رأس الرد المستلم بأنفسه (كما هو موضح في RFC 2068)، فإن آلية التخزين المؤقت ستعمل بشكل جيد. ETag و/أو Content-Location، إذا كان نفس الطلب يجب أن يرجع بهذا العنوان. 2رد 00. Expires، Cache-التحكم، وأيضاً/Vary، إذا كان قيمته قد تختلف عن القيمة الم对应ة للردود الأخرى للعامل نفسه من قبل.
إذا كان طلب الرد هذا يستخدم التحقق القوي من المخزن المؤقت، فإن الرد يجب أن لا يحتوي على أي عناوين كيان أخرى؛ وإلا (على سبيل المثال، إذا كان الطلب المبني على شرط الحصول على بيانات يستخدم التحقق الضعيف من المخزن المؤقت)، يمنع الرد من إضافة أي عناوين كيان أخرى؛ هذا يمنع التباين بين محتوى كيان المخزن المؤقت وتعليمات عناوين كيانات التحديث. إذا كان 304 الرد يشير إلى أن الكيان ليس مخزنًا حاليًا، يجب على نظام التخزين تجاهل الرد وإرسال طلبات متكررة بدون قيود.
إذا كان 304 الرد المُستلم لتعديل مسجل المخزن يجب على نظام التخزين تحديث المسجل كله ليعكس قيم جميع الحقول التي تم تعديلها في الرد. |
| 305 | يجب الوصول إلى المورد المطلوب من خلال الوسيط المحدد. يتم تقديم معلومات URI الوسيط المحدد في حقل Location. يجب على المستلم إرسال طلبات منفصلة متكررة للوصول إلى الموارد المطلوبة من خلال هذا الوسيط. يمكن إنشاء 305 الرد. ملاحظة: لا يوجد تحديد واضح 305 الرد في RFC 2068 لإعادة توجيه طلب واحد، وهو يمكن إنشاؤه فقط من قبل الخادم الأصلي. يمكن أن يؤدي تجاهل هذه القيود إلى عواقب أمنية خطيرة. |
| 306 | في أحدث إصدار من المspecification، 306 كود الحالة ليس مستخدمًا بعد الآن. |
| 307 | المورد المطلوب يرد الآن مؤقتًا على الطلب من URI مختلف. لأن مثل هذه التوجيهات مؤقتة، يجب أن يستمر الجانب العملي في إرسال طلبات مستقبلية إلى العنوان الأصلي. هذا الرد يمكن تخزينه في الملف فقط إذا تم تحديده في Cache-التحكم أو الإقامة. يجب إعادة توجيه URI المؤقتة في حقل Location من الرد. ما لم يكن هذا طلبًا HEAD، يجب أن يحتوي الكيان المتجاوب على رابط هипيرلينك يشير إلى URI الجديد ووصف قصير. لأن بعض المتصفحات لا تعترف بالـ 307 الرد، يجب إضافة هذه المعلومات لكي يتمكن المستخدم من فهمها وطلب الوصول إلى URI الجديد.
إذا كان هذا ليس طلبًا GET أو HEAD، فإن المتصفح يمنع التوجيه التلقائي إلا إذا تم تأكيده من قبل المستخدم، لأن حالات الطلب قد تتغير نتيجة لذلك. |
| 400 | 1. معانيها خاطئة، ولا يمكن للخادم فهم الطلب الحالي. يجب ألا يقدم الجانب العملي الطلب مرة أخرى إلا إذا تم تعديله. 2. معلمات الطلب خاطئة. |
| 401 | يتطلب الطلب الحالي التحقق من هوية المستخدم. يجب أن يحتوي الرد على رأس WWW-رأس التحقق لطلب الموارد المطلوبة لطلب معلومات المستخدم. يمكن للجانب العملي إعادة تقديم الطلب بملء معلومات رأس التحقق المناسبة. إذا كان الطلب الحالي يحتوي بالفعل على شهادات التحقق، 401 يعبر الرد عن رفض الخادم لتلك الشهادات. إذا كان 401 يحتوي الرد على نفس استعلام التحقق كما في الرد السابق، وقد حاول المتصفح التحقق على الأقل مرة واحدة، فإن المتصفح يجب أن يعرض للمستخدم معلومات الكيان الموجودة في الرد، لأن هذه المعلومات قد تحتوي على معلومات تشخيصية ذات صلة. انظر إلى RFC 2617. |
| 402 | يُخصص هذا كود الحالة لمتطلبات مستقبلية محتملة. |
| 403 | فهم الخادم الطلب، لكن رفض تنفيذه. على عكس 401 لا يفيد التحقق، ويجب ألا يتم تكرار الطلب. إذا لم يكن هذا طلب HEAD، ويريد الخادم توضيح السبب الذي لا يمكن تنفيذ الطلب، فإن سبب الرفض يجب أن يتم وصفه داخل الكيان. بالطبع، يمكن للخادم أيضًا رد 404 لا يريد أن يحصل الجانب العملي على أي معلومات. |
| 404 | فشل الطلب، ولم يتم العثور على الموارد المطلوبة على الخادم. لا توجد معلومات لتخبر المستخدم ما إذا كانت الحالة مؤقتة أم دائمة. إذا كان الخادم على علم بالحالة، 410 يجب استخدام كود الحالة لإعلام الموارد القديمة بأنها غير متاحة دائمًا بسبب بعض آلية التكوين الداخلية وأنها ليس لديها عنوان للقفز إليه. 404 كود الحالة يستخدم على نطاق واسع عندما لا يريد الخادم كشف السبب الذي رفض الطلب أو لا يوجد رد مناسب متاح. |
| 405 | لا يمكن استخدام طريقة الطلب المحددة في سطر الطلب لطلب المصدر المطلوب. يجب أن يعود الرد بكؤوس الأعمدة التي تشير إلى قائمة الطرق التي يمكن قبولها من قبل المصدر الحالي. منذ أن تكتب طرق PUT وDELETE موارد على الخادم، لا تدعم معظم خوادم الويب أو تسمح بشكل افتراضي بالطريقة الطلب أعلاه وسيعود بـ 405 الخطأ لطلبات مثل هذه. |
| 406 | لا تتوافق خصائص المحتوى للمصدر المطلوب مع الشروط المحددة في جدول الأعمدة الطلب، لذا لا يمكن توليد كيان الرد. ما لم يكن هذا طلب HEAD، يجب أن يعود الرد بكيان يسمح للمستخدم أو المتصفح باختيار الخصائص الأكثر ملاءمة للكيان والقائمة على العناوين. يتم تحديد نمط الكيان بناءً على نوع الوسائط المحدد في Content-جدول الأعمدة للنوع. يمكن للbrowser أن يختار أفضل خيار بناءً على النمط وقدراته الخاصة. ومع ذلك، لا تعرف النصوص أي معايير لاتخاذ مثل هذه الإختيارات التلقائية. |
| 407 | مثل 401 رد، باستثناء أن الجانب التابع للعميل يجب أن يتم التحقق من هوية على خادم الوكيل. يجب على خادم الوكيل رد Proxy-التحقق من الهوية للتحقق من الهوية. يمكن للجانب التابع للعميل رد Proxy-جدول الأعمدة للتحقق من الهوية. انظر RFC 2617. |
| 408 | انتهت وقت الطلب. لم يتم إكمال إرسال الطلب من قبل الجانب التابع للعميل في الوقت الذي كان الخادم مستعدًا للانتظار. يمكن للجانب التابع للعميل إعادة تقديم الطلب في أي وقت دون أي تغيير. |
| 409 | الطلب لا يمكن إكماله بسبب تضارب مع حالة المصدر المطلوب حاليًا. يتم إعطاء هذا الرقم فقط إذا كان يتم افتراض أن المستخدم قادر على حل التضارب وإعادة تقديم طلب جديد. يجب أن تحتوي الردود على معلومات كافية للمستخدم لتحديد مصدر التضارب. يحدث التضارب عادةً أثناء معالجة طلبات PUT. على سبيل المثال، في إصدار-بيئة التحقق، إذا كانت معلومات إصدار المرفقة بـ PUT-طلب تعديل تم تقديمه لموارد معينة يتعارض مع سابق (ثالث-جهة الطلب، يجب على الخادم رد 409 خطأ يخبر المستخدم بأن الطلب لم يتم إكماله.
في هذه النقطة، من المحتمل أن تحتوي كيان الرد على مقارنة بين الإصدارين المتعارضين، حتى يتمكن المستخدم من إعادة تقديم النسخة المدمجة. |
| 410 | لم يعد الموارد المطلوبة متاحة على الخادم وليس لديه عنوان توجيه معروف. يجب اعتبار هذا حالة دائمة. إذا كان ذلك ممكنًا، يجب على الجانب المستقل مع قدرات تعديل الرابط إزالة جميع المراجع إلى هذا العنوان بموافقة المستخدم. إذا لم يعرف الخادم أو لم يتمكن من تحديد ما إذا كان هذا الحالة دائمة، فإنه 404 يجب استخدام رمز الحالة. ما لم يُحدد خلاف ذلك، يمكن تخزين هذا الرد. غرض 410 الرد هو لتحسين المدير الموقع، لإبلاغ المستخدم بأن الموارد ليست متاحة بعد الآن، وأن مالك الخادم يريد حذف جميع الاتصالات البعيدة لهذا الموارد.
هذا النوع من الحدث شائع في الوقت-محدود، القيمة-خدمات إضافية. بشكل مماثل، 410 يستخدم الرد على العملاء لتعليم أن الموارد التي كانت تخص شخصًا ما ليست متاحة بعد الآن على موقع الخادم الحالي. من الطبيعي، يعتمد هذا تمامًا على مالك الخادم ما إذا كان يريد وضع جميع الموارد غير المتاحة دائمًا كـ' 410 الغياب '، وكيفية الحفاظ على هذا العلامة. |
| 411 | يرفض الخادم قبول الطلب دون تحديد محتوى.-مقدار الرأس.-مقدار الرأس التي تشير إلى طول جسم الطلب، يمكن للجهة المستقلة تقديم الطلب مرارًا وتكرارًا. |
| 412 | فشل الخادم في استيفاء واحد أو أكثر من الشروط الأساسية عند التحقق من أنها قد تم تقديمها في حقل عنوان الطلب. يسمح هذا الرقم الحالي للعميل الجانب بتعيين الشروط الأساسية في البيانات المتعددة المطلوبة (بيانات عنوان الطلب) عند استخراج الموارد، مما يمنع تطبيق طريقة الطلب على موارد غير تلك التي يريد. |
| 413 | يرفض الخادم معالجة الطلب الحالي لأن الطلب يقدم بيانات كيان أكثر مما يرغب أو يستطيع التعامل معه الخادم. في هذه الحالة، يمكن للخادم إغلاق الاتصال لمنع العميل الجانب من مواصلة إرسال الطلب. إذا كان هذا الوضع مؤقتًا، يجب على الخادم رد بـ Retry-بعد عنوان الرد لتعليم العميل الجانب كمقدار الوقت الذي يمكنه محاولته مجددًا. |
| 414 | يكون URI المطلوب أطول مما يمكن للخادم تفسيره، لذا يرفض الخادم خدمة الطلب. هذا نادر، والأحوال الشائعة تشمل: تحويل نموذج يجب أن يستخدم طريقة POST إلى طريقة GET، مما يؤدي إلى أن يكون السلسلة الاستعلام (Query String) طويلة جدًا. تحويل URI "الثقوب السوداء"، مثل كل تحويل يستخدم URI القديم كجزء من URI الجديدة، مما يؤدي إلى أن تصبح URI طويلة بعد عدة تحويلات. يحاول العميل الهجوم على الخادم باستخدام ثغرات أمنية موجودة في بعض الخوادم.
يستخدم هذا النوع من الخادم نطاقًا ثابتًا-مكتبة طول للقراءة أو التلاعب بالURI المطلوب. عندما تتجاوز معلمات GET قيمة معينة، قد يحدث تجاوز مكتبة، مما يؤدي إلى تنفيذ كود عشوائي [1]. يجب على الخوادم التي لا تحتوي على مثل هذه الثغرات رد بـ 414 كود حالة. |
| 415 | للمетод الحالي للطلب والمورد المطلوب، ليس صيغة الكيان المقدم في الطلب مدعومة من قبل الخادم، لذا يتم رفض الطلب. |
| 416 | إذا كان يحتوي الطلب على عنوان نطاق Range، وأي نطاقات بيانات معينة في Range لا تتطابق مع نطاق المتاح الحالي للمورد، وIf-لم يتم تعريف عنوان نطاق في الطلب، يجب على الخادم رد بـ 416 كود الحالة. إذا استخدم Range نطاقًا من البيانات، فإن هذا الوضع يعني أن موقع البايت الأول من جميع نطاقات البيانات المحددة في الطلب يتجاوز طول المصدر الحالي. يجب أيضًا أن يشمل الخادم Content-عنوان entity Range بالإضافة إلى 416 كود الحالة لتحديد طول المصدر الحالي. هذا الرد ممنوع أيضًا من استخدام multipart/byteranges كمحتواها-نوع. |
| 417 | لا يمكن أن يرضي الخادم المحتوى المتوقع المحدد في عنوان الطلب Expect، أو أن يكون الخادم بروتوكول استنساخ وله أدلة واضحة بأن المحتوى المتوقع لا يمكن أن يرضى في العقد التالي من المسار الحالي. |
| 421 | عدد الاتصالات إلى الخادم من عنوان الإنترنت للبروتوكول حيث يقع الجانب المستهلك الحالي يتجاوز الحد الأقصى المسموح به من قبل الخادم. عادةً، يشير عنوان الإنترنت للبروتوكول هنا إلى عنوان الجانب المستهلك كما يراه الخادم (مثل عنوان جسر المستخدم أو بروتوكول استنساخ المستخدم). في هذه الحالة، قد يشمل عدد الاتصالات أكثر من مستخدمين منتهيين. |
| 422 | عدد الاتصالات إلى الخادم من عنوان الإنترنت للبروتوكول حيث يقع الجانب المستهلك الحالي يتجاوز الحد الأقصى المسموح به من قبل الخادم. عادةً، يشير عنوان الإنترنت للبروتوكول هنا إلى عنوان الجانب المستهلك كما يراه الخادم (مثل عنوان جسر المستخدم أو بروتوكول استنساخ المستخدم). في هذه الحالة، قد يشمل عدد الاتصالات أكثر من مستخدمين منتهيين. |
| 422 | تم ترتيب الطلب بشكل صحيح، لكن لم يتم الرد عليه بسبب خطأ لغوي. (RFC 4918 WebDAV) 423 مقفل المصدر الحالي محجوز. (RFC 4918 WebDAV) |
| 424 | فشل الطلب الحالي بسبب خطأ في طلب سابق، مثل PROPPATCH. (RFC 4918 WebDAV) |
| 425 | محدد في مشروع WebDav Collections المتقدمة، لكن ليس في بروتوكول WebDAV المتماثل (RFC 3658). |
| 426 | يجب على الجانب المستهلك التبديل إلى TLS/1.0. (RFC 2817) |
| 449 | تم توسيعه بواسطة مايكروسوفت، يجب إعادة محاولة الطلبات بعد تنفيذ الإجراء المناسب. |
| 500 | واجه الخادم موقفاً غير متوقعاً منعته من إكمال الطلب. عادةً، يحدث هذا المشكلة عندما تفشل برمجة الخادم. |
| 501 | لا يدعم الخادم ميزة تتطلبها الطلب الحالي. عندما لا يستطيع الخادم التعرف على الأسلوب المطلوب ولا يمكنه دعم طلبه لأي مصدر. |
| 502 | عندما يحاول خادم يعمل كمدخل أو بروتوكول استنساخ تنفيذ طلب، يلتقط استجابة غير صالحة من خادم السلسلة العلوية. |
| 503 | لا يمكن للخادم حاليًا معالجة الطلبات بسبب صيانة الخادم المؤقتة أو التزحم. هذه حالة مؤقتة وسيعود إلى الحالة الطبيعية بعد فترة من الزمن. إذا كان يمكن تنبؤ بوقت التأخير، يمكن أن يشمل الرد retry-بعد رأس لتحديد وقت التأخير. إذا كان وقت التأخير قابل للتنبؤ به، يمكن أن يشمل الرد retry-بعد عدم تقديم المعلومات، يجب على الجانب الآخر التعامل معها كما لو كانت 5رد 00. ملاحظة: وجود 503 رمز الحالة لا يعني أن الخادم يجب أن يستخدمه في حالة التزحم. بعض الخوادم ترغب ببساطة في رفض اتصال العميل. |
| 504 | عندما يحاول خادم يعمل كمعبر أو بروتوكول وساطة تنفيذ الطلب، يفشل في استقبال استجابة من خادم علوية (محدد بواسطة URI، مثل HTTP، FTP، LDAP) أو خادم ثانوي (مثل DNS) في وقت مناسب. ملاحظة: بعض خوادم الوساطة تعود بـ 400 أو 5خطأ 00 عند انتهاء وقت الاستفسار في DNS |
| 505 | لا يدعم الخادم أو يرفض دعم إصدار HTTP المستخدم في الطلب. هذا يعني أن الخادم لا يمكن أو لن يستخدم نفس الإصدار مثل الجانب الآخر. يجب أن يشمل الرد كيانًا يصف لماذا لا يدعم الإصدار وما هي البروتوكولات التي يدعمها الخادم. |
| 506 | ممتد بواسطة بروتوكول التفاوض على المحتوى الواضح (RFC 2295)، هذا يمثل خطأ داخلي في تكوين الخادم: يتم تكوين المتغير الذي يتم التفاوض عليه بشكل واضح لاستخدامه بنفسه في التفاوض على المحتوى الواضح، وبالتالي ليس تركيزًا مناسبًا في عملية التفاوض. |
| 507 | لا يمكن للخادم تخزين المحتوى اللازم لإكمال الطلب. يعتبر هذا الحالة مؤقتة. WebDAV (RFC 4918) |
| 509 | وصل الخادم إلى حد الحد الأقصى للعرض السريع. هذا ليس رمز حالة رسمي، ولكن يستخدم على نطاق واسع. |
| 510 | لم يتم استيفاء السياسات المطلوبة للحصول على الموارد. (RFC 2774) |
