صندوق أدوات iToolify
رمز حالة Httpمعنى رمز الحالة
100يجب على العميل الاستمرار في إرسال الطلب. يتم استخدام هذه الاستجابة المؤقتة لإخطار العميل بأن جزءًا من طلباته قد تم تلقيه بواسطة الخادم ولم يتم رفضه. يجب على العميل الاستمرار في إرسال ما تبقى من الطلب ، أو تجاهل هذه الاستجابة إذا كان الطلب قد اكتمل. يجب على الخادم إرسال استجابة نهائية إلى العميل بعد اكتمال الطلب.
101لقد فهم الخادم طلب العميل وسيبلغ العميل من خلال رأس رسالة Upgrade باستخدام بروتوكولات مختلفة لإكمال الطلب. بعد إرسال آخر سطر فارغ من هذه الاستجابة ، سيتحول الخادم إلى البروتوكولات المحددة في رأس رسالة Upgrade. يجب اتخاذ تدابير مماثلة فقط عندما يكون من المفيد تبديل بروتوكولات جديدة. على سبيل المثال ، يعد التبديل إلى إصدار HTTP الجديد أكثر فائدة من الإصدار القديم ، أو التبديل إلى بروتوكول في الوقت الفعلي والمزامنة لنقل الموارد التي تستفيد من هذه الميزات.
102رمز الحالة الموسع بواسطة WebDAV(RFC 2518) يعني أن المعالجة ستستمر.
200إذا كان الطلب ناجحًا ، فسيعود رأس الاستجابة أو جسم البيانات المرغوب فيه مع هذه الاستجابة.
201تم تنفيذ الطلب ، وتم إنشاء مورد جديد وفقًا للاحتياجات المطلوبة ، وتم إرجاع URI الخاص به مع معلومات رأس الموقع. إذا تعذر إنشاء الموارد المطلوبة في الوقت المناسب ، فيجب العودة إلى "202 Accepted".
202تم قبول الطلب من قبل الخادم ، ولكن لم تتم معالجته بعد. كما قد يتم رفضه ، في النهاية قد يتم تنفيذ الطلب أو لا يتم تنفيذه. في حالة التشغيل غير المتزامن ، لا توجد طريقة أكثر ملاءمة من إرسال رمز الحالة هذا. الغرض من رد رمز الحالة 202 هو السماح للخادم بقبول طلبات العمليات الأخرى (مثل عملية قائمة على الدُفعات يتم تنفيذها مرة واحدة فقط في اليوم) ، دون الحاجة إلى إبقاء العميل على اتصال بالخادم حتى اكتمال عملية الدُفعات. يجب أن تحتوي الاستجابة لقبول معالجة الطلب والعودة إلى رمز الحالة 202 على بعض المعلومات التي تشير إلى الحالة الحالية للمعالجة في الكيان العائد ، بالإضافة إلى مؤشرات إلى مراقبة حالة المعالجة أو التنبؤ بالحالة ، بحيث يمكن للمستخدم تقدير ما إذا كانت العملية قد اكتملت.
203نجح الخادم في معالجة الطلب ، لكن معلومات عنصر الرأس المادي التي تم إرجاعها ليست مجموعة محددة بشكل صحيح على الخادم الأصلي ، ولكنها نسخة من جهة محلية أو خارجية. قد تكون المعلومات الحالية مجموعة فرعية أو مجموعة فائقة من الإصدار الأصلي. على سبيل المثال ، قد تؤدي البيانات الوصفية التي تحتوي على مورد إلى معرفة الخادم الأصلي بالمعلومات الوصفية الفائقة. ليس من الضروري استخدام رمز الحالة هذا ، وهو مناسب فقط إذا لم يتم استخدام رمز الحالة هذا للرد ، فسيتم إرجاع 200 OK.
204نجح الخادم في معالجة الطلب ، لكنه لا يحتاج إلى إرجاع أي محتوى مادي ، ويأمل في إرجاع المعلومات الوصفي المحدثة. قد يتم إرجاع الاستجابة إلى المعلومات الوصفي الجديدة أو المحدثة من خلال شكل الرأس المادي. إذا كانت معلومات الرأس هذه موجودة ، فيجب أن تعكس المتغيرات المطلوبة. إذا كان العميل عبارة عن متصفح ، فيجب أن يحتفظ متصفح المستخدم بالصفحة التي تم إرسال الطلب إليها دون إنشاء أي تغييرات في عرض المستند ، حتى إذا كان يجب تطبيق المعلومات الوصفي الجديدة أو المحدثة على عرض نشاط متصفح المستخدم وفقًا للمواصفات وثيقة. نظرًا لأن استجابة 204 ممنوعة من تضمين أي رسالة ، فإنها تنتهي دائمًا بأول سطر فارغ خلف رأس الرسالة.
205نجح الخادم في معالجة الطلب، ولم يُرجع أي محتوى. ولكن على عكس الاستجابة 204، تتطلب الاستجابة التي تعود بهذا الرمز إعادة تعيين عرض المستند من قبل المُرسِل. تُستخدم هذه الاستجابة بشكل رئيسي لإعادة تعيين النموذج فورًا بعد استلام إدخال المستخدم، بحيث يمكن للمستخدم بدء إدخال جديد بسهولة. تمامًا مثل応答 204، يُحظر أيضًا تضمين أي محتوى في هذا الرد، ويُنهى بالسطر الفارغ الأول الذي يلي رأس الرسالة.
206تمت معالجة بعض طلبات GET بنجاح بواسطة الخادم. تستخدم أدوات تنزيل HTTP مثل FlashGet أو Thunder مثل هذه الاستجابات لتحقيق استمرار نقطة التوقف أو تقسيم مستند كبير إلى أجزاء تنزيل متعددة في نفس الوقت. يجب أن يحتوي الطلب على معلومات رأس Range للإشارة إلى نطاق المحتوى الذي يريد العميل الحصول عليه ، وقد يحتوي على If-Range كشرط للطلب. يجب أن تحتوي الاستجابة على مجال الرأس التالي: يتم استخدام Content-Range للإشارة إلى نطاق المحتوى الذي يتم إرجاعه في هذه الاستجابة ؛ إذا كان نوع Content-Type عبارة عن تنزيل متعدد الأقسام لـ multipart/byteranges ، فيجب أن يحتوي كل قسم من أقسام multipart على مجال Content-Range للإشارة إلى نطاق المحتوى في هذه الفقرة. إذا كانت الاستجابة تحتوي على Content-Length ، فيجب أن تتطابق قيمتها مع عدد البايت الحقيقي في نطاق المحتوى الذي يتم إرجاعه. Date ETag و/أو Content-Location ، إذا كان يجب إعادة نفس الطلب إلى استجابة 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 ، يجب أن تتضمن الاستجابة كيانًا يحتوي على قائمة بخصائص المورد والعناوين حتى يتمكن المستخدم أو المتصفح من اختيار عنوان إعادة التوجيه الأنسب. يتم تحديد تنسيق هذا الكيان من خلال التنسيق المحدد بواسطة Content-Type. قد يتخذ المتصفح تلقائيًا الخيار الأنسب بناءً على تنسيق الاستجابة وقدرات المتصفح نفسه. بالطبع ، لا تحدد مواصفات RFC 2616 كيفية إجراء مثل هذا الاختيار التلقائي. إذا كان الخادم نفسه لديه بالفعل الخيار المفضل للتعليقات ، فيجب الإشارة إلى URI للتعليقات في الموقع ؛ قد يستخدم المتصفح قيمة الموقع هذه كعنوان لإعادة التوجيه التلقائي. بالإضافة إلى ذلك ، هذه الاستجابة قابلة للتخزين المؤقت ما لم يتم تحديدها بشكل إضافي.
301تم نقل المورد المطلوب إلى موقع جديد بشكل دائم ، ويجب أن يستخدم أي مرجع لهذا المورد في المستقبل أحد URI العديدة التي تم إرجاعها في هذه الاستجابة. إذا كان ذلك ممكنًا ، يجب على العميل الذي لديه وظيفة تحرير الرابط تعديل العنوان المطلوب تلقائيًا إلى العنوان الذي تم إعادته من الخادم. هذه الاستجابة قابلة للتخزين المؤقت ما لم يتم تحديدها بشكل إضافي. يجب إرجاع 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 على جسم رسالة؛ لذا تنتهي دائمًا بأول سطر فارغ بعد رأس الرسالة. يجب أن يتضمن الرد رأسين على الأقل: Date، إلا إذا كان الخادم لا يحتوي على ساعة. إذا كان الخادم الذي لا يحتوي على ساعة يتبع هذه القواعد أيضًا، فيمكن للخادم الوكيل والعميل إضافة حقل Date بشكل مستقل إلى رؤوس الاستجابة المستلمة (كما هو منصوص عليه في RFC 2068)، وستعمل آلية التخزين المؤقت كما ينبغي. ETag و/أو Content-Location، إذا كان من المفترض أن تُعيد نفس الطلب استجابة برمز 200. ينتهي الصلاحية، وControl التخزين المؤقت، و/أو Vary، إذا كانت قيمتها قد تختلف عن القيم المقابلة في استجابات أخرى لنفس المتغيرات.إذا كان استجابة الطلب هذه قد استخدمت التحقق القوي من الكاش، فلا ينبغي أن تتضمن هذه الاستجابة أي رؤوس كيان أخرى؛ وإلا (على سبيل المثال، إذا استخدم طلب GET مشروط التحقق الضعيف من الكاش)، فيُحظر على هذه الاستجابة تضمين أي رؤوس كيان أخرى؛ وذلك لتجنب عدم التوافق بين محتوى الكيان المخزَّن في الكاش ومعلومات رأس الكيان المحدَّثة. إذا أشار استجابة 304 إلى عدم وجود نسخة مخبأة للكيان الحالي، فيتعين على نظام التخزين المؤقت تجاهل هذه الاستجابة وإعادة إرسال الطلب دون تحديد أي شروط. إذا تم استلام استجابة 304 تطلب تحديث إحدى كيانات التخزين المؤقت، فيتعين على نظام التخزين المؤقت تحديث الكيان بالكامل ليعكس قيم جميع الحقول التي تم تحديثها في الاستجابة.
305يجب أن تمر الموارد المطلوبة من خلال وكيل معين ليتم الوصول إليها. سيعطي مجال الموقع معلومات URI حيث يوجد الوكيل المحدد ، ويحتاج المستلم إلى إرسال طلب منفصل بشكل متكرر ، ويمكن الوصول إلى المورد المقابل من خلال هذا الوكيل. يمكن فقط للخادم الأصلي إنشاء استجابة 305. ملاحظة: لا يوجد رد صريح 305 في RFC 2068 لإعادة توجيه طلب منفصل ، ولا يمكن إنشاؤها إلا بواسطة الخادم الأصلي. يمكن أن يؤدي تجاهل هذه القيود إلى عواقب أمنية خطيرة.
306في أحدث إصدار من المواصفات ، لم يعد رمز الحالة 306 مستخدما.
307الموارد المطلوبة تستجيب الآن بشكل مؤقت للطلبات من URI مختلفة. نظرًا لأن إعادة التوجيه هذه مؤقتة ، يجب على العميل الاستمرار في إرسال الطلبات اللاحقة إلى العنوان الأصلي. هذه الاستجابة قابلة للتخزين المؤقت فقط إذا تم تحديدها في Cache-Control أو Expires. يجب إرجاع URI المؤقت الجديد في مجال الموقع المستجيب. ما لم يكن هذا طلب HEAD ، يجب أن يحتوي الكيان المستجيب على ارتباط تشعبي وتعليمات موجزة إلى URI الجديد. نظرًا لأن بعض المتصفحات لا يمكنها التعرف على استجابة 307 ، يجب إضافة المعلومات اللازمة المذكورة أعلاه حتى يتمكن المستخدمون من فهم وإصدار طلبات الوصول إلى URI الجديدة. إذا لم يكن هذا طلبًا للحصول على GET أو HEAD ، فإن المتصفح يحظر إعادة التوجيه التلقائي ما لم يتم تأكيد ذلك من قبل المستخدم ، لأن شروط الطلب قد تتغير نتيجة لذلك.
4001. دلالات خاطئة ، ولا يمكن للخادم فهم الطلب الحالي. يجب على العميل عدم تكرار هذا الطلب ما لم يتم تعديله. 2. معلمات الطلب غير صحيحة.
401يتطلب الطلب الحالي التحقق من صحة المستخدم. يجب أن تحتوي الاستجابة على رأس معلومات WWW-Authenticate للمورد المطلوب لطلب معلومات المستخدم. يمكن للعميل إرسال طلب يحتوي على معلومات رأس Authorization المناسبة بشكل متكرر. إذا كان الطلب الحالي يحتوي بالفعل على شهادة Authorization ، فإن الاستجابة 401 تعني أن التحقق من الخادم قد رفض تلك الشهادات. إذا احتوت استجابة 401 على نفس استفسار المصادقة مثل الاستجابة السابقة ، وحاول المتصفح التحقق مرة واحدة على الأقل ، فيجب أن يعرض المتصفح للمستخدم معلومات الكيان المضمنة في الاستجابة ، لأن معلومات الكيان هذه قد تحتوي على معلومات تشخيصية ذات صلة. انظر RFC 2617.
402يتم حجز رمز الحالة للطلب المحتمل في المستقبل.
403لقد فهم الخادم الطلب ، لكنه رفض تنفيذه. على عكس استجابة 401 ، لا تقدم المصادقة أي مساعدة ، ولا ينبغي تقديم هذا الطلب بشكل متكرر. إذا لم يكن هذا طلبًا HEAD ، ويريد الخادم توضيح سبب عدم تنفيذ الطلب ، فيجب وصف سبب الرفض في الكيان. بالطبع ، يمكن للخادم أيضًا إرجاع استجابة 404 ، إذا كان لا يريد العميل الحصول على أي معلومات.
404فشل الطلب ، ولم يتم العثور على الموارد المطلوبة على الخادم. لا توجد معلومات تخبر المستخدمين ما إذا كان هذا الوضع مؤقتًا أو دائمًا. إذا كان الخادم يعرف الموقف ، فيجب استخدام رمز الحالة 410 لإبلاغ المورد القديم بأنه غير متوفر بشكل دائم بسبب بعض مشاكل آلية التكوين الداخلية ، ولا يوجد عنوان يمكن نقله. 404 يستخدم رمز الحالة هذا على نطاق واسع عندما لا يريد الخادم الكشف عن سبب رفض الطلب أو لا توجد استجابة مناسبة أخرى متاحة.
405طريقة الطلب المحددة في سطر الطلب لا يمكن استخدامها لطلب الموارد المعنية. يجب أن ي返َعَ هذا الرد رأس Allow لتحديد قائمة بطرق الطلبات التي تقبلها الموارد الحالية. نظرًا لأن طرفيّ PUT وDELETE يقومان بعمليات كتابة على الموارد الموجودة على الخادم، فإن معظم خوادم الويب لا تدعم هذين الأسلوبين من طلبات HTTP، أو أنها تمنع استخدامهما في إعداداتها الافتراضية. ولذلك، تُرجع هذه الخوادم رمز خطأ 405 (Method Not Allowed) عند تلقي أي طلب باستخدام هذين الأسلوبين.
406لا يمكن توليد كيان الاستجابة لأن خصائص محتوى الموارد المطلوبة لا تلبّي الشروط الواردة في رأس الطلب. ما لم يكن الطلب من نوع HEAD، فيجب أن يحتوي هذا الاستجابة على وحدة بيانات تتضمن معلومات تتيح للمستخدم أو للمتصفح اختيار أنسب خصائص الكيان بالإضافة إلى قائمة بالعناوين. يُحدد تنسيق الكيان بنوع الوسائط المعرَّف في رأس Content-Type. يمكن للمتصفح اختيار الخيار الأفضل تلقائيًا بناءً على التنسيق وقدراته الخاصة. إلا أنَّ المواصفة لا تُحدِّد أيًّا من المعايير التي تُتَّخذ لإجراء مثل هذا الاختيار التلقائي.
407على غرار استجابة 401 ، يجب أن تتم المصادقة على العميل على الخادم الوكيل. يجب على الخادم الوكيل إرجاع Proxy-Authenticate للاستعلام عن الهوية. يمكن للعميل إرجاع رأس معلومات Proxy-Authorization للتحقق. انظر RFC 2617.
408طلب مهلة. لم يكمل العميل إرسال طلب خلال وقت انتظار الخادم. يمكن للعميل تقديم هذا الطلب مرة أخرى في أي وقت دون أي تغييرات.
409بسبب التضارب مع الوضع الحالي للموارد المطلوبة ، لا يمكن إكمال الطلب. لا يُسمح باستخدام هذا الرمز إلا في ظل هذه الظروف: يعتبر المستخدم قادرًا على حل النزاعات وسيعيد تقديم طلب جديد. يجب أن تحتوي الاستجابة على معلومات كافية حتى يتمكن المستخدمون من اكتشاف مصدر الصراع. يحدث الصراع عادة في معالجة طلبات PUT. على سبيل المثال ، في بيئة استخدام فحص الإصدار ، تتعارض معلومات الإصدار المرفقة بطلب تعديل مورد معين مقدم من PUT مع طلب سابق (طرف ثالث) ، ثم يجب على الخادم إرجاع خطأ 409 في هذا الوقت. لا يمكن إكمال طلب المستخدم. في هذه المرحلة ، من المحتمل أن يتم تضمين مقارنة الاختلافات بين الإصدارين المتضاربتين في الكيان المستجيب ، بحيث يمكن للمستخدم إعادة التقديم إلى الإصدارات الجديدة اللاحقة.
410لم تعد الموارد المطلوبة متاحة على الخادم ، ولا يوجد عنوان إعادة توجيه معروف. وينبغي اعتبار هذه الحالة دائمة. إذا أمكن ، يجب على العميل الذي لديه وظيفة تحرير الرابط حذف جميع المراجع إلى هذا العنوان بعد الحصول على إذن المستخدم. إذا كان الخادم لا يعرف أو لا يستطيع تحديد ما إذا كان هذا الوضع دائمًا ، فيجب عليك استخدام رمز الحالة 404. هذه الاستجابة قابلة للتخزين المؤقت ما لم تكن هناك تعليمات إضافية. الغرض من استجابة 410 هو بشكل أساسي مساعدة مشرف الموقع على الحفاظ على موقع الويب ، وإخطار المستخدمين بأن المورد لم يعد متاحًا ، ويأمل مالك الخادم أن يتم أيضًا حذف جميع الاتصالات البعيدة لهذا المورد. مثل هذه الحوادث شائعة في الخدمات ذات القيمة المضافة المحدودة الوقت. وبالمثل ، يتم استخدام استجابة 410 أيضًا لإبلاغ العميل أنه في موقع الخادم الحالي ، لم تعد الموارد التي تنتمي في الأصل إلى فرد معين متاحة. بالطبع ، ما إذا كان يجب وضع علامة على جميع الموارد غير المتاحة بشكل دائم على أنها "410 Gone" ، وما إذا كان يجب الحفاظ على هذه العلامة لفترة طويلة ، يعتمد كليًا على مالك الخادم.
411رفض الخادم قبول الطلب دون تحديد رأس Content-Length. بعد إضافة رأس Content-Length صالح يشير إلى طول رسالة الطلب ، يمكن للعميل تقديم الطلب مرة أخرى.
412فشل الخادم في تلبية واحد أو أكثر من المتطلبات الأساسية عند التحقق من ذلك في حقل الرأس المطلوب. يسمح رمز الحالة هذا للعميل بتعيين المتطلبات الأساسية في المعلومات الوصية المطلوبة (بيانات حقل رأس الطلب) عند الحصول على المورد ، وذلك لتجنب تطبيق طريقة الطلب على موارد أخرى غير المحتوى الذي يريده.
413رفض الخادم معالجة الطلب الحالي لأن حجم بيانات الكيان المقدمة في الطلب يتجاوز الحد الذي يقبل الخادم معالجته أو يستطيع معالجته. في مثل هذه الحالات، يجوز للخادم إغلاق الاتصال لمنع العميل من مواصلة إرسال هذا الطلب. إذا كان هذا الحال مؤقتًا، فيجب على الخادم إرجاع رأس استجابة Retry-After ليخبر العميل بالوقت الذي يمكنه فيه إعادة المحاولة.
414يتجاوز طول URI المطلوب الطول الذي يمكن للخادم تفسيره ، لذلك يرفض الخادم تقديم خدمة للطلب. هذا نادر نسبيًا ، وتشمل الظروف العادية: يصبح إرسال النموذج الذي يجب أن يستخدم طريقة POST طريقة GET ، مما يؤدي إلى سلسلة الاستعلام طويلة جدًا. إعادة توجيه URI "الثقب الأسود" ، مثل كل إعادة توجيه تأخذ URI القديم كجزء من URI الجديد ، مما يؤدي إلى URI طويل جدًا بعد عدة عمليات إعادة توجيه. يحاول العميل استغلال الثغرات الأمنية الموجودة في بعض الخوادم لمهاجمة الخوادم. يستخدم هذا النوع من الخوادم مخزنًا مؤقتًا بطول ثابت لقراءة أو تشغيل URI المطلوبة. عندما تتجاوز المعلمات بعد GET قيمة معينة ، قد يؤدي ذلك إلى تجاوز سعة المخزن المؤقت ، مما يؤدي إلى تنفيذ التعليمات البرمجية التعسفية [1]. يجب إعادة الخادم الذي لا يحتوي على مثل هذه الثغرات الأمنية إلى رمز الحالة 414.
415بالنسبة للطريقة المطلوبة حاليًا والموارد المطلوبة ، فإن الكيان المقدم في الطلب ليس هو التنسيق المدعوم في الخادم ، وبالتالي يتم رفض الطلب.
416إذا كان الطلب يحتوي على رأس طلب Range ، ولا يتزامن أي نطاق بيانات محدد في Range مع النطاق المتاح للمورد الحالي ، ولم يتم تحديد رأس طلب If-Range في الطلب ، فيجب على الخادم إرجاع رمز الحالة 416. إذا كان Range يستخدم نطاق البايت ، فإن هذه الحالة تعني أن موضع البايت الأول لجميع نطاقات البيانات المحددة للطلب يتجاوز طول المورد الحالي. يجب أن يحتوي الخادم أيضًا على رأس كيان Content-Range أثناء إرجاع رمز الحالة 416 للإشارة إلى طول المورد الحالي. يحظر هذا الرد أيضًا استخدام multipart/byteranges كنوع Content-Type.
417لا يمكن للخادم تلبية المحتوى المتوقع المحدد في رأس الطلب Expect ، أو أن هذا الخادم هو خادم وكيل ، ولديه دليل واضح على أنه لا يمكن تلبية محتوى Expect في العقدة التالية من التوجيه الحالي.
421يتجاوز عدد الاتصالات من عنوان IP الخاص بالعميل الحالي إلى الخادم الحد الأقصى لترخيص الخادم. بشكل عام ، يشير عنوان IP هنا إلى عنوان العميل (مثل بوابة المستخدم أو عنوان الخادم الوكيل) الذي يتم رؤيته من الخادم. في هذه الحالة ، قد يشمل حساب عدد الاتصالات أكثر من مستخدم طرفي واحد.
422يتجاوز عدد الاتصالات من عنوان IP الخاص بالعميل الحالي إلى الخادم الحد الأقصى لترخيص الخادم. بشكل عام ، يشير عنوان IP هنا إلى عنوان العميل (مثل بوابة المستخدم أو عنوان الخادم الوكيل) الذي يتم رؤيته من الخادم. في هذه الحالة ، قد يشمل حساب عدد الاتصالات أكثر من مستخدم طرفي واحد.
422تم تنسيق الطلب بشكل صحيح ، لكنه لا يستطيع الاستجابة بسبب الأخطاء الدلالية. (RFC 4918 WebDAV)423 Locked يتم تأمين الموارد الحالية. (RFC 4918 WebDAV)
424فشل الطلب الحالي بسبب خطأ حدث في طلب سابق ، مثل PROPPATCH. (RFC 4918 WebDAV)
425تم تعريفه في مسودة مجموعة Webداف Advanced Collections ، لكنه لم يظهر في "بروتوكول مجموعة تسلسل WebDAV" (RFC 3658).
426يجب أن يتحول العميل إلى TLS/1.0. (RFC 2817)
449تم توسيعه بواسطة Microsoft ، ويجب إعادة المحاولة بعد تنفيذ الإجراءات المناسبة.
500واجه الخادم وضعًا غير متوقع ، مما تسبب في عدم قدرته على إكمال معالجة الطلب. بشكل عام ، ستظهر هذه المشكلة عندما يكون رمز برنامج الخادم خاطئًا.
501لا يدعم الخادم وظيفة معينة مطلوبة للطلب الحالي. عندما لا يتعرف الخادم على طريقة الطلب ولا يمكنه دعم طلبه لأي مورد.
502عندما يحاول الخادم الذي يعمل كبوابة أو وكيل تنفيذ الطلب ، يتلقى استجابة غير صالحة من خادم المنبع.
503نظرًا لصيانة الخادم المؤقت أو التحميل الزائد ، لا يمكن للخادم حاليًا معالجة الطلب. هذا الوضع مؤقت وسيتم استعادته بعد فترة. إذا كان من الممكن توقع وقت التأخير ، فيمكن تضمين رأس Retry-After في الاستجابة للإشارة إلى وقت التأخير هذا. إذا لم يتم إعطاء معلومات Retry-After هذه ، فيجب على العميل التعامل معها بطريقة تتعامل مع استجابة 500. ملاحظة: لا يعني وجود رمز الحالة 503 أنه يجب على الخادم استخدامه عند التحميل الزائد. بعض الخوادم ليست أكثر من الرغبة في رفض اتصال العميل.
504عندما يحاول الخادم الذي يعمل كبوابة أو وكيل تنفيذ الطلب ، فإنه يفشل في تلقي استجابة في الوقت المناسب من خادم المنبع (خادم محدد بواسطة URI ، مثل HTTP أو FTP أو LDAP) أو خادم مساعد (مثل DNS). ملاحظة: تقوم بعض خوادم الوكيل بإرجاع خطأ 400 أو 500 في مهلة الاستعلام عن DNS
505لا يدعم الخادم ، أو يرفض دعم إصدار HTTP المستخدم في الطلب. هذا يعني أن الخادم غير قادر أو غير راغب في استخدام نفس الإصدار من العميل. يجب أن تحتوي الاستجابة على كيان يصف سبب عدم دعم الإصدار والبروتوكولات التي يدعمها الخادم.
506تم توسيعه بواسطة "اتفاقية التفاوض بشأن المحتوى الشفاف" (RFC 2295) ، مما يعني أن الخادم به خطأ في التكوين الداخلي: يتم تخصيص موارد تغيير التفاوض المطلوبة لاستخدامها في مفاوضات المحتوى الشفافة ، لذلك فهي ليست نقطة مهمة مناسبة في معالجة التفاوض.
507لا يمكن للخادم تخزين المحتوى اللازم لإكمال الطلب. ويعتبر هذا الوضع مؤقتا. WebDAV(RFC 4918)
509يصل الخادم إلى حد عرض النطاق الترددي. هذا ليس رمز حالة رسمي ، لكنه لا يزال يستخدم على نطاق واسع.
510لم يتم تلبية الاستراتيجيات اللازمة للحصول على الموارد. (RFC 2774)
البصمة الخاصة بك:

صندوق أدوات iToolifyملاحة

روابط ودية:iCMS