أدوات عبر الإنترنت
رمز حالة HTTP معنى رمز الحالة
100 يجب أن يستمر العميل في إرسال الطلبات. يتم استخدام هذه الاستجابة المؤقتة لإعلام العميل بأن جزءًا من طلبه قد تم استلامه من قبل الخادم ولم يتم رفضه. يجب على العميل الاستمرار في إرسال ما تبقى من الطلب، أو تجاهل هذا الرد إذا كان الطلب مكتملاً. يجب على الخادم إرسال رد نهائي للعميل عند اكتمال الطلب.
101 فهم الخادم طلب العميل وسيقوم بإخطار العميل عبر رأس رسالة الترقية لاستخدام بروتوكول مختلف لإكمال الطلب. بعد إرسال السطر الفارغ الأخير من هذه الاستجابة، سيقوم الخادم بالتبديل إلى تلك البروتوكولات المحددة في رأس رسالة الترقية. يجب القيام بذلك فقط إذا كان التبديل إلى بروتوكول جديد أكثر فائدة. على سبيل المثال، يكون التبديل إلى إصدار جديد من HTTP أكثر فائدة من إصدار أقدم، أو التبديل إلى بروتوكول في الوقت الحقيقي ومتزامن لتقديم الموارد التي تستفيد من هذه الميزات.
102 تمثل رموز الحالة، التي تم توسيعها بواسطة WebDAV (RFC 2518)، استمرار المعالجة.
200 تم تنفيذ الطلب بنجاح وسيتم إرجاع رأس الاستجابة أو هيئة البيانات المطلوبة من قبل الطلب مع هذه الاستجابة.
201 تم تنفيذ الطلب وتم إنشاء مورد جديد كما هو مطلوب من قبل الطلب وتم إرجاع URI الخاص به مع رأس الموقع. في حال تعذّر إنشاء المورد المطلوب في الوقت المناسب، يجب إرجاع "202 مقبول".
202 لقد قبل الخادم الطلب، لكنه لم يعالجه بعد. مثلما قد يتم رفضه، قد يتم تنفيذ الطلب أو لا يتم تنفيذه في النهاية. في سياق العمليات غير المتزامنة، لا يوجد شيء أكثر ملاءمة من إرسال رمز الحالة هذا. الغرض من إرجاع استجابة برمز الحالة 202 هو السماح للخادم بقبول الطلبات من عمليات أخرى (مثل عملية قائمة على دفعات يتم تنفيذها مرة واحدة فقط في اليوم) دون الحاجة إلى إبقاء العميل متصلاً بالخادم حتى تكتمل العملية الدفعية بالكامل. يجب أن تتضمن الاستجابة التي تقبل طلبًا للمعالجة وتُرجع رمز الحالة 202 في الكيان الذي تم إرجاعه بعض المعلومات التي تشير إلى الحالة الحالية للعملية، بالإضافة إلى مؤشر إلى مراقب حالة المعالجة أو توقع الحالة حتى يتمكن المستخدم من تقدير ما إذا كانت العملية قد اكتملت أم لا.
203 لقد عالج الخادم الطلب بنجاح، لكن المعلومات الوصفية لرأس الكيان الذي تم إرجاعه ليست مجموعة نهائية صالحة على الخادم الأصلي، بل نسخة من طرف محلي أو طرف ثالث. قد تكون المعلومات الحالية مجموعة فرعية أو مجموعة فائقة من النسخة الأصلية. على سبيل المثال، قد تتسبب البيانات الوصفية التي تحتوي على موارد في معرفة الخادم الأصلي بالمعلومات الوصفية الفائقة. استخدام رمز الحالة هذا غير مطلوب وهو مناسب فقط إذا كانت الاستجابة ستُرجع 200 موافق بدونه.
204 قام الخادم بمعالجة الطلب بنجاح، ولكنه لا يحتاج إلى إرجاع أي محتوى مادي ويريد إرجاع معلومات وصفية محدثة. قد تُرجع الاستجابة معلومات وصفية جديدة أو محدثة في شكل رؤوس كيانات. إذا كانت هذه الرؤوس موجودة، فيجب أن تتوافق مع المتغيرات المطلوبة. إذا كان العميل متصفحًا، فيجب أن يحتفظ متصفح المستخدم بالصفحة التي تم إرسال الطلب عليها دون أي تغييرات في عرض المستند، على الرغم من أنه وفقًا للمواصفات يجب تطبيق المعلومات الوصفية الجديدة أو المحدثة على المستند في العرض النشط لمتصفح المستخدم. نظرًا لأن الاستجابة 204 ممنوعة من احتواء أي نص رسالة، فإنها تنتهي دائمًا بالسطر الفارغ الأول بعد رأس الرسالة.
205 عالج الخادم الطلب بنجاح ولم يُرجع أي شيء. ولكن على عكس الاستجابة 204، فإن الاستجابة التي تُرجع رمز الحالة هذا تطلب من الطالب إعادة تعيين عرض المستند. تُستخدم هذه الاستجابة في المقام الأول لإعادة تعيين النموذج مباشرةً بعد قبول إدخال المستخدم حتى يتمكن المستخدم من بدء إدخال آخر بسهولة. مثل الاستجابة 204، يُمنع احتواء هذه الاستجابة على أي نص رسالة وتنتهي بالسطر الفارغ الأول بعد رأس الرسالة.
206 قام الخادم بمعالجة جزء من طلب GET بنجاح. تستخدم أدوات تنزيل HTTP مثل FlashGet أو Thunderbolt هذا النوع من الاستجابة لإجراء تنزيلات متقطعة أو لتقسيم مستند كبير إلى أجزاء تنزيل متعددة في نفس الوقت. يجب أن يحتوي الطلب على رأس نطاق للإشارة إلى نطاق المحتوى الذي يرغب العميل في تلقيه، وقد يحتوي على "إذا كان النطاق" كشرط للطلب. يجب أن تحتوي الاستجابة على حقول الرؤوس التالية: Content-Range للإشارة إلى نطاق المحتوى الذي تم إرجاعه في هذه الاستجابة؛ في حالة التنزيل متعدد الأجزاء بنوع محتوى متعدد الأجزاء/النطاقات، يجب أن يحتوي كل مقطع متعدد الأجزاء على حقل Content-Range يشير إلى نطاق المحتوى في ذلك المقطع. إذا كان الرد يحتوي على طول المحتوى، فيجب أن تتطابق قيمته مع العدد الحقيقي للبايت في نطاق المحتوى الذي يُرجعه. علامة ETag و/أو موقع المحتوى، إذا كان يجب أن يُرجع نفس الطلب استجابة 200. تنتهي و/أو Cache-Control و/أو Vary، إذا كانت قيمها قد تختلف عن الاستجابات الأخرى التي تحتوي على نفس المتغيرات. تنتهي و/أو Cache-Control و/أو Vary، إذا كانت قيمها قد تكون مختلفة عن قيم الاستجابات السابقة الأخرى لنفس المتغيرات. يجب ألا تحتوي هذه الاستجابة على رؤوس كيانات أخرى إذا كان الطلب يستخدم التحقق من صحة التخزين المؤقت القوي إذا كان النطاق، ويجب ألا تحتوي على رؤوس كيانات أخرى إذا كان الطلب يستخدم التحقق من صحة التخزين المؤقت الضعيف إذا كان النطاق ضعيفًا؛ وهذا لتجنب التناقضات بين محتوى الكيان المخزن مؤقتًا ومعلومات رأس الكيان المحدثة. وبخلاف ذلك، يجب أن تحتوي هذه الاستجابة على جميع حقول رؤوس الكيانات التي كان يجب إرجاعها في جميع استجابات 200 التي كان يجب إرجاعها. إذا كانت علامة ETag أو رؤوس آخر تعديل غير متطابقة تماماً، يجب أن تحظر ذاكرة التخزين المؤقت من جانب العميل دمج المحتوى الذي تم إرجاعه في الاستجابة 206 مع أي محتوى تم تخزينه مؤقتاً مسبقاً. يُحظر على أي ذاكرة تخزين مؤقت لا تدعم رأسي النطاق ونطاق المحتوى تخزين المحتوى الذي تم إرجاعه في الاستجابة 206 مؤقتًا.
207 يعني رمز الحالة، كما تم توسيعه بواسطة WebDAV (RFC 2518)، أن نص الرسالة اللاحق سيكون رسالة 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 يحظر أن تحتوي الردود على نص الرسالة، وبالتالي تنتهي دائمًا بالسطر الأول الفارغ بعد رأس الرسالة. يجب أن تحتوي الاستجابة على العناوين التالية: التاريخ، إلا إذا كان الخادم لا يملك ساعة. إذا كان الخادم بدون ساعة يتبع هذه القواعد، فيمكن للخادم الوكيل والعميل إضافة حقل التاريخ إلى رأس الاستجابة الوارد من تلقاء نفسه (كما هو محدد في RFC 2068)، وستعمل آلية التخزين المؤقت بشكل صحيح.ETag و/أو Content-Location، إذا كان الطلب نفسه سيعيد استجابة 200.Expires Expires و/أو Cache-Control و/أو Vary، إذا كانت القيمة قد تكون مختلفة عن القيمة المقابلة للاستجابات السابقة الأخرى لنفس المتغير. إذا كان طلب الاستجابة هذا يستخدم التحقق القوي من صحة ذاكرة التخزين المؤقت، فيجب ألا تحتوي هذه الاستجابة على رؤوس كيانات أخرى؛ وإلا (على سبيل المثال، طلب GET المشروط يستخدم التحقق الضعيف من صحة ذاكرة التخزين المؤقت)، يحظر أن تحتوي هذه الاستجابة على رؤوس كيانات أخرى؛ وهذا يتجنب التناقضات بين محتوى الكيان المخزن مؤقتًا ومعلومات رأس الكيان المحدثة. إذا كانت الاستجابة 304 تشير إلى أن الكيان غير مخزن مؤقتًا حاليًا، فيجب على نظام التخزين المؤقت تجاهل الاستجابة وتكرار الطلب بدون القيد. في حالة تلقي استجابة 304 تطلب تحديث إدخال ذاكرة التخزين المؤقت، يجب أن يقوم نظام التخزين المؤقت بتحديث الإدخال بالكامل ليعكس قيم جميع الحقول التي تم تحديثها في الاستجابة.
305 يجب أن يتم الوصول إلى المورد المطلوب من خلال الوكيل المحدد. سيعطي حقل الموقع معلومات حول URI حيث يوجد الوكيل المحدد، وسيحتاج المستلم إلى إرسال طلب منفصل بشكل متكرر للوصول إلى المورد من خلال هذا الوكيل. يمكن للخادم الأصلي فقط إنشاء استجابة 305. ملاحظة: ليس من الواضح من RFC 2068 أن استجابة 305 تهدف إلى إعادة توجيه طلب واحد ولا يمكن إنشاؤها إلا من قبل الخادم الأصلي. قد يؤدي تجاهل هذه القيود إلى عواقب أمنية خطيرة.
306 في الإصدار الأخير من المواصفات، لم يعد رمز الحالة 306 مستخدمًا.
307 يستجيب المورد المطلوب الآن بشكل مؤقت للطلب من مورد URI مختلف. نظرًا لأن عمليات إعادة التوجيه هذه مؤقتة، يجب على العملاء الاستمرار في إرسال الطلبات المستقبلية إلى العنوان الأصلي. هذه الاستجابة قابلة للتخزين المؤقت فقط إذا تم تحديدها في 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 تم اختفاء" على جميع الموارد غير المتاحة بشكل دائم والمدة التي يجب الحفاظ على هذه العلامة.
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)
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)
سجلات الوصول:

مجموعة الأدوات عبر الإنترنت