أدوات عبر الإنترنت
رموز حالة Http معنى رمز الحالة
100 يجب أن يستمر العميل في إرسال الطلبات. يتم استخدام هذا الرد المؤقت لإعلام العميل بأن جزءًا من طلبه قد تم استلامه من قبل الخادم ولم يتم رفضه. يجب على العميل الاستمرار في إرسال ما تبقى من الطلب، أو تجاهل هذا الرد إذا كان الطلب قد اكتمل. يجب على الخادم إرسال رد نهائي للعميل عند اكتمال الطلب.
101 يكون الخادم قد فهم طلب العميل وسيقوم بإعلام العميل عبر رأس الترقية بأنه تم استخدام بروتوكول مختلف لإكمال الطلب. بعد إرسال السطر الفارغ الأخير من الاستجابة، سيقوم الخادم بالتبديل إلى البروتوكولات المحددة في رأس الترقية. يجب القيام بذلك فقط إذا كان التبديل إلى البروتوكول الجديد أكثر فائدة. على سبيل المثال، قد يكون التبديل إلى إصدار جديد من HTTP مفيدًا على إصدار أقدم، أو التبديل إلى بروتوكول متزامن في الوقت الحقيقي لتقديم الموارد التي تستفيد من هذه الميزات.
102 تشير رموز الحالة، التي تم تمديدها بواسطة WebDAV (RFC 2518)، إلى استمرار المعالجة.
200 تم تنفيذ الطلب بنجاح، وسيتم إرجاع رؤوس الاستجابة أو هيئة البيانات المطلوبة من قبل الطلب مع الاستجابة.
201 تم تنفيذ الطلب وتم إنشاء مورد جديد استجابةً للطلب، وتم إرجاع URI الخاص به مع رأس الموقع. في حال تعذّر إنشاء المورد المطلوب في الوقت المناسب، سيتم إرجاع ما يلي'202 Accepted'。
202 قبل الخادم الطلب، لكنه لم يعالجه بعد. مثلما قد يتم رفضه، قد يتم تنفيذ الطلب أو لا يتم تنفيذه في النهاية. في حالة العمليات غير المتزامنة، لا يوجد شيء أكثر ملاءمة من إرسال رمز الحالة هذا. الغرض من إرجاع استجابة 202 هو السماح للخادم بقبول الطلبات من عمليات أخرى (مثل عملية قائمة على دفعات يتم تنفيذها مرة واحدة فقط في اليوم) دون أن يضطر العميل إلى الحفاظ على الاتصال بالخادم حتى تكتمل العملية الدفعية. يجب أن تتضمن الاستجابة التي تقبل طلبًا للمعالجة وتعيد رمز الحالة 202 في الكيان الذي تم إرجاعه بعض المعلومات التي تشير إلى الحالة الحالية للعملية، بالإضافة إلى مؤشر إلى مراقب حالة المعالجة أو توقع الحالة، بحيث يمكن للمستخدم تقدير ما إذا كانت العملية قد اكتملت أم لا.
203 قام الخادم بمعالجة الطلب بنجاح، لكن المعلومات الوصفية لرأس الكيان الذي تم إرجاعه ليست مجموعة نهائية صالحة على الخادم الأصلي، بل نسخة من طرف محلي أو طرف ثالث. قد تكون المعلومات الحالية مجموعة فرعية أو مجموعة فائقة من المعلومات الأصلية. على سبيل المثال، قد تؤدي البيانات الوصفية التي تحتوي على موارد إلى معرفة الخادم الأصلي بالمعلومات الوصفية الفائقة. استخدام رمز الحالة هذا غير مطلوب ويكون مناسبًا فقط إذا كانت الاستجابة ستُرجع 200 موافق بدونه.
204 قام الخادم بمعالجة الطلب بنجاح، ولكنه لا يحتاج إلى إرجاع أي محتوى مادي ويريد إرجاع معلومات تعريفية محدثة. قد تُرجع الاستجابة معلومات تعريفية جديدة أو محدثة على شكل رؤوس كيانات. إذا كانت هذه الرؤوس موجودة، فيجب أن تتوافق مع المتغيرات المطلوبة. إذا كان العميل متصفحًا، يجب أن يحتفظ متصفح المستخدم بالصفحة التي تم إرسال الطلب عليها دون أي تغييرات في عرض المستند، على الرغم من أن المعلومات الوصفية الجديدة أو المحدثة يجب، وفقًا للمواصفات، أن يتم تطبيقها على المستند في العرض النشط لمتصفح المستخدم. نظرًا لأن الاستجابة 204 ممنوعة من احتواء أي نص رسالة، فإنها تنتهي دائمًا بالسطر الفارغ الأول بعد رأس الرسالة.
205 يعالج الخادم الطلب بنجاح ولا يُرجع أي شيء. ومع ذلك، على عكس الاستجابة 204، فإن الاستجابة التي تُرجع رمز الحالة هذا تطلب من الطالب إعادة تعيين عرض المستند. تُستخدم هذه الاستجابة في المقام الأول لإعادة تعيين النموذج مباشرةً بعد قبول إدخال المستخدم حتى يتمكن المستخدم من بدء إدخال آخر بسهولة. مثل الاستجابة 204، يحظر على هذه الاستجابة أن تحتوي على أي نص رسالة وتنتهي بأول سطر فارغ بعد رأس الرسالة.
206 قام الخادم بمعالجة جزء من طلب GET بنجاح. تستخدم أدوات تنزيل HTTP مثل FlashGet أو Thunderbolt هذا النوع من الاستجابة لإجراء تنزيلات متقطعة أو لتقسيم ملف كبير إلى عدة تنزيلات في نفس الوقت. يجب أن يحتوي الطلب على رأس نطاق للإشارة إلى نطاق المحتوى الذي يرغب العميل في تلقيه، وقد يحتوي على "إذا كان النطاق" كشرط للطلب. يجب أن تحتوي الاستجابة على حقول الرؤوس التالية: Content-Range للإشارة إلى نطاق المحتوى الذي تم إرجاعه في هذه الاستجابة، أو في حالة التنزيلات متعددة الأجزاء بنوع محتوى متعدد الأجزاء/التبادلات، يجب أن يحتوي حقل Content-Range في كل مقطع متعدد الأجزاء للإشارة إلى نطاق المحتوى في ذلك المقطع. إذا كان الرد يحتوي على طول المحتوى، فيجب أن تتطابق قيمته مع العدد الحقيقي للبايت في نطاق المحتوى الذي يُرجعه. تنتهي و/أو Cache-Control و/أو Vary، إذا كانت قيمها قد تختلف عن قيم الاستجابات السابقة الأخرى التي تحتوي على نفس المتغيرات. يجب ألا تحتوي هذه الاستجابة على رؤوس كيانات أخرى إذا كان الطلب يستخدم التحقق القوي من صحة التخزين المؤقت في حالة النطاق، ويجب ألا تحتوي على رؤوس كيانات أخرى إذا كان الطلب يستخدم التحقق الضعيف من صحة التخزين المؤقت في حالة النطاق؛ وهذا لتجنب التناقضات بين محتوى الكيان المخزن مؤقتًا ومعلومات رأس الكيان المحدثة. وبخلاف ذلك، يجب أن تحتوي هذه الاستجابة على جميع حقول رؤوس الكيانات التي كان يجب إرجاعها في الاستجابة 200. إذا كانت علامة ETag أو رؤوس آخر تعديل غير متطابقة تمامًا، يجب ألا تسمح ذاكرة التخزين المؤقت من جانب العميل بدمج المحتوى الذي تم إرجاعه في الاستجابة 206 مع أي محتوى تم تخزينه مؤقتًا مسبقًا. يحظر على أي ذاكرة تخزين مؤقت لا تدعم رأسي النطاق ونطاق المحتوى التخزين المؤقت للمحتوى الذي تم إرجاعه بواسطة الاستجابة 206.
207 رموز الحالة الموسعة بواسطة WebDAV(RFC 2518) يعني رمز الحالة، كما تم تمديده بواسطة WebDAV، أن نص الرسالة اللاحقة سيكون رسالة XML وقد يحتوي على سلسلة من رموز الاستجابة المنفصلة، اعتمادًا على عدد الطلبات الفرعية السابقة.
300 يحتوي المورد المطلوب على سلسلة من الردود البديلة، لكل منها عنوانه الخاص ومعلومات التفاوض الخاصة به التي يعتمد عليها المتصفح. الأمر متروك للمستخدم أو المتصفح لاختيار العنوان المفضل لإعادة التوجيه. ما لم يكن هذا طلب HEAD، يجب أن تتضمن الاستجابة كيانًا عبارة عن قائمة بخصائص المورد والعناوين التي يمكن للمستخدم أو المتصفح اختيار عنوان إعادة التوجيه الأنسب منها. يتم تحديد تنسيق هذا الكيان من خلال تنسيق تعريف نوع المحتوى. قد يقوم المتصفح تلقائياً بالاختيار الأنسب بناءً على تنسيق الاستجابة وإمكانيات المتصفح الخاصة. وبالطبع، لا تحدد مواصفات RFC 2616 كيفية إجراء هذا التحديد التلقائي. إذا كان الخادم نفسه لديه بالفعل خيار إرجاع مفضل، فيجب تحديد URI الخاص بالإرجاع في الموقع؛ قد تستخدم المتصفحات قيمة الموقع هذه كعنوان لإعادة التوجيه التلقائي. بالإضافة إلى ذلك، تكون الاستجابة قابلة للتخزين المؤقت ما لم يتم تحديد خلاف ذلك.
301 تم نقل المورد المطلوب إلى الموقع الجديد بشكل دائم، وأي مراجع مستقبلية له يجب أن تستخدم أحد مراجع URIs العديدة التي تم إرجاعها في هذه الاستجابة. إذا أمكن، يجب على العملاء الذين لديهم إمكانيات تحرير الروابط تغيير العنوان المطلوب تلقائيًا إلى العنوان الذي تم إرجاعه من الخادم. هذه الاستجابة أيضاً قابلة للتخزين المؤقت ما لم يتم تحديد خلاف ذلك. يجب إرجاع URI الدائم الجديد في حقل الموقع في الاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي كيان الاستجابة على ارتباط تشعبي إلى URI الجديد ووصف قصير. إذا لم يكن هذا طلب GET أو HEAD، فيحظر على المتصفح إعادة التوجيه تلقائيًا ما لم يؤكد المستخدم ذلك، حيث قد تتغير شروط الطلب نتيجة لذلك. ملحوظة: بالنسبة لبعض المتصفحات التي تستخدم بروتوكول HTTP/1.0، عندما ترسل طلب POST وتحصل على استجابة 301، فإن طلب إعادة التوجيه التالي سيكون GET.
302 يستجيب المورد المطلوب الآن بشكل مؤقت للطلب من مورد URI مختلف. نظرًا لأن إعادة التوجيه هذه مؤقتة، يجب أن يستمر العميل في إرسال الطلبات المستقبلية إلى العنوان الأصلي. تكون الاستجابة قابلة للتخزين المؤقت فقط إذا تم تحديدها في Cache-Control أو Expires. يجب إرجاع 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 يحظر أن تحتوي الردود 304 على نص الرسالة، وبالتالي تنتهي دائمًا بالسطر الأول الفارغ بعد رأس الرسالة. يجب أن تحتوي الاستجابة على معلومات الرأس التالية: التاريخ، إلا إذا كان الخادم لا يملك ساعة. إذا كان الخادم الذي لا يملك ساعة يتبع هذه القواعد، فيمكن للخادم الوكيل والعميل إضافة حقل التاريخ إلى رأس الاستجابة الوارد من تلقاء نفسه (كما هو محدد في RFC 2068)، وستعمل آلية التخزين المؤقت بشكل صحيح.ETag و/أو Content-Location، إذا كان ينبغي أن يُرجع الطلب نفسه استجابة 200. Expires و/أو Cache-Control و/أو Vary، إذا كانت قيمها قد تكون مختلفة عن قيم الاستجابات السابقة الأخرى التي لها نفس المتغيرات. إذا كان طلب الاستجابة يستخدم التحقق القوي من صحة ذاكرة التخزين المؤقت، فيجب ألا تحتوي الاستجابة على رؤوس كيانات إضافية؛ وإلا (على سبيل المثال، طلب GET المشروط يستخدم التحقق الضعيف من صحة ذاكرة التخزين المؤقت)، يحظر أن تحتوي الاستجابة على رؤوس كيانات إضافية؛ وهذا يتجنب التناقضات بين محتوى الكيان المخزن مؤقتًا ومعلومات رأس الكيان المحدثة. إذا كانت الاستجابة 304 تشير إلى أن الكيان غير مخزن مؤقتًا حاليًا، فيجب على نظام التخزين المؤقت تجاهل الاستجابة وتكرار الطلب بدون القيد. إذا تم تلقي استجابة 304 تطلب تحديث إدخال ذاكرة التخزين المؤقت، يجب أن يقوم نظام التخزين المؤقت بتحديث الإدخال بالكامل ليعكس قيم جميع الحقول التي تم تحديثها في الاستجابة.
305 يجب أن يتم الوصول إلى المورد المطلوب من خلال وكيل محدد. سيعطي حقل الموقع معلومات حول URI للوكيل المحدد، وسيحتاج المستلم إلى إرسال طلب منفصل بشكل متكرر للوصول إلى المورد من خلال هذا الوكيل. يمكن للخادم الأصلي فقط إنشاء استجابة 305. ملاحظة: ليس من الواضح من RFC 2068 أن الاستجابة 305 تهدف إلى إعادة توجيه طلب واحد ولا يمكن إنشاؤها إلا من قبل الخادم الأصلي. يمكن أن يؤدي تجاهل هذه القيود إلى عواقب أمنية خطيرة.
306 في الإصدار الأخير من المواصفات، لم يعد رمز الحالة 306 مستخدمًا.
307 تستجيب الموارد المطلوبة الآن بشكل مؤقت للطلبات الواردة من عناوين URIs مختلفة. نظرًا لأن إعادة التوجيه هذه مؤقتة، يجب أن يستمر العملاء في إرسال الطلبات المستقبلية إلى العنوان الأصلي. هذه الاستجابة قابلة للتخزين المؤقت فقط إذا تم تحديدها في Cache-Control أو Expires. يجب إرجاع URI المؤقت الجديد في حقل الموقع في الاستجابة. ما لم يكن هذا طلب HEAD، يجب أن يحتوي كيان الاستجابة على ارتباط تشعبي إلى URI الجديد ووصف قصير. نظرًا لأن بعض المتصفحات لا تتعرف على الاستجابة 307، فمن الضروري إضافة المعلومات المذكورة أعلاه حتى يتمكن المستخدم من فهم وطلب الوصول إلى URI الجديد. إذا لم يكن هذا طلب GET أو HEAD، فإن المتصفح يحظر إعادة التوجيه التلقائي، ما لم يؤكد المستخدم ذلك، لأن شروط الطلب قد تتغير.
400 1، خطأ دلالي، لا يمكن فهم الطلب الحالي من قبل الخادم. ما لم يتم تعديله، يجب على العميل عدم تكرار الطلب. 2، معلمات الطلب خاطئة.
401 يتطلب الطلب الحالي مصادقة المستخدم. يجب أن تحتوي الاستجابة على رأس WWW-Authenticate للمورد المطلوب لطلب معلومات المستخدم. يمكن للعميل إعادة إرسال الطلب مع معلومات رأس التخويل المناسبة. إذا كان الطلب الحالي يحتوي بالفعل على بيانات اعتماد التخويل، فإن الاستجابة 401 تعني أن الخادم يتحقق من رفض بيانات الاعتماد تلك. إذا كانت استجابة 401 تحتوي على نفس استعلام المصادقة مثل الاستجابة السابقة، وكان المتصفح قد قام بالفعل بمحاولة واحدة على الأقل للمصادقة، فيجب على المتصفح أن يعرض للمستخدم معلومات الكيان الموجودة في الاستجابة، حيث قد تحتوي معلومات الكيان هذه على معلومات تشخيصية ذات صلة. راجع RFC 2617.
402 رمز الحالة هذا محجوز للمتطلبات المستقبلية المحتملة.
403 فهم الخادم الطلب، لكنه يرفض تنفيذه. على عكس الاستجابة 401، لا توفر المصادقة أي مساعدة، ويجب عدم إعادة إرسال الطلب. إذا لم يكن هذا طلب HEAD، وأراد الخادم أن يكون قادراً على تحديد سبب عدم إمكانية تنفيذ الطلب، فيجب وصف سبب الرفض في الكيان. بالطبع، يمكن للخادم أيضًا إرجاع استجابة 404 إذا كان لا يريد أن يحصل العميل على أي معلومات.
404 فشل الطلب، لم يتم العثور على المورد المطلوب على الخادم. لا توجد معلومات تخبر المستخدم ما إذا كانت الحالة مؤقتة أو دائمة. إذا كان المخدّم على علم بالوضع، فيجب عليه استخدام رمز الحالة 410 لإعلام المخدّم بأن المورد القديم غير متوفر بشكل دائم بسبب بعض آليات التكوين الداخلية وأنه لا توجد إعادة توجيه متاحة. 404 يستخدم على نطاق واسع عندما لا يريد المخدّم الكشف عن سبب رفض الطلب أو عندما لا تتوفر استجابة أخرى مناسبة.
405 لا يمكن استخدام طريقة الطلب المحددة في سطر الطلب لطلب المورد المقابل. يجب أن تُرجع الاستجابة رأس سماح يشير إلى قائمة أساليب الطلب المقبولة للمورد الحالي. نظرًا لأن أسلوبي PUT و DELETE يكتبان إلى المورد على الخادم، فإن معظم خوادم الويب لا تدعمهما أو تسمح بهما افتراضيًا وستقوم بإرجاع خطأ 405 لمثل هذه الطلبات.
406 لا تفي خصائص محتوى المورد المطلوب بالشروط الموجودة في رأس الطلب ولا يمكن إنشاء كيان استجابة. ما لم يكن هذا طلب HEAD، يجب أن تُرجع الاستجابة كيانًا يحتوي على خصائص الكيان الأكثر ملاءمة وقائمة بالعناوين التي يمكن للمستخدم أو المتصفح الاختيار من بينها. يتم تحديد تنسيق الكيان من خلال نوع الوسائط المحدد في رأس نوع المحتوى. يمكن للمتصفح الاختيار الأفضل بناءً على التنسيق وإمكانياته الخاصة. ومع ذلك، لا تحدد المواصفات أي معايير لاتخاذ مثل هذه الاختيارات التلقائية.
407 يشبه الرد 401، باستثناء أنه يجب على العميل المصادقة مع الخادم الوكيل. يجب أن يقوم الخادم الوكيل بإرجاع مصادقة-وكيل-مصادقة لاستجواب الهوية. قد يقوم العميل بإرجاع رأس Proxy-Authorization للمصادقة. راجع 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 إذا كان الطلب يحتوي على رأس طلب نطاق، وأي نطاقات بيانات محددة في النطاق لا تتطابق مع النطاقات المتوفرة للمورد الحالي، ولا يحدد الطلب رأس طلب إذا كان النطاق، فيجب أن يُرجع الخادم رمز الحالة 416. إذا كان النطاق يستخدم نطاقات البايت، فهذا يعني أن البايت الأول من جميع نطاقات البيانات المحددة في الطلب يتجاوز طول المورد الحالي. يجب أن يتضمن الخادم أيضًا رأس كيان نطاق المحتوى الذي يحدد طول المورد الحالي مع رمز الحالة 416. يحظر على هذا الرد أيضًا استخدام متعدد الأجزاء/النطاقات كنوع المحتوى الخاص به.
417 لا يمكن تحقيق المحتوى المتوقع المحدد في رأس الطلب "توقع" من قبل الخادم، أو أن الخادم هو خادم وكيل لديه دليل واضح على أن محتوى "توقع" لا يمكن تحقيقه في العقدة التالية في المسار الحالي.
421 يتجاوز عدد الاتصالات بالخادم من عنوان IP الخاص بالعميل الحالي الحد الأقصى المسموح به من قبل الخادم. عادةً ما يشير عنوان IP هنا إلى عنوان العميل كما يظهر من الخادم (على سبيل المثال، بوابة المستخدم أو عنوان الخادم الوكيل). في هذه الحالة، قد يشارك أكثر من مستخدم نهائي واحد في عدد الاتصالات.
422 يتجاوز عدد الاتصالات من عنوان IP الخاص بالعميل الحالي إلى الخادم الحد الأقصى المسموح به من قبل الخادم. عادةً ما يشير عنوان IP هنا إلى عنوان العميل كما يظهر من الخادم (على سبيل المثال، بوابة المستخدم أو عنوان الخادم الوكيل). في هذه الحالة، قد يشارك أكثر من مستخدم نهائي واحد في عدد الاتصالات.
422 تم تنسيق الطلب بشكل صحيح، ولكن تعذر الاستجابة له لاحتوائه على أخطاء دلالية. (RFC 4918 WebDAV) 423 مقفل المورد الحالي مقفل. (RFC 4918 WebDAV) 423 مقفل
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)
الوصول إلى السجلات: