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