قائمة رموز حالة HTTP

يجب على العميل متابعة طلبه. تشير هذه الاستجابة المؤقتة إلى أن كل شيء على ما يرام حتى الآن وأنه يجب على العميل متابعة الطلب أو تجاهله إذا كان قد انتهى بالفعل.

يقوم الخادم بتبديل البروتوكولات كما طلب العميل عبر رأس طلب الترقية (Upgrade).

WebDAV؛ استلم الخادم الطلب وهو قيد المعالجة، ولكن لا توجد استجابة متاحة بعد. هذا يمنع العميل من انتهاء المهلة وافتراض فقدان الطلب.

يرسل الخادم بعض الرؤوس قبل رسالة HTTP النهائية. يُستخدم للسماح للعميل ببدء التحميل المسبق للموارد بينما لا يزال الخادم يُعد الاستجابة الرئيسية.

نجح الطلب. يعتمد معنى 'النجاح' على طريقة HTTP: GET: تم جلب المورد ونقله في نص الرسالة. HEAD: توجد رؤوس الكيان في نص الرسالة. POST أو PUT: يتم نقل المورد الذي يصف نتيجة الإجراء في نص الرسالة. TRACE: يحتوي نص الرسالة على رسالة الطلب كما استقبلها الخادم.

تم تلبية الطلب وأسفر عن إنشاء مورد جديد. يتم إنشاء المورد الجديد فعليًا قبل إرسال هذه الاستجابة ويتم إرجاع المورد الجديد في نص الرسالة، ويكون موقعه إما عنوان URL للطلب أو محتوى رأس الموقع (Location).

تم قبول الطلب للمعالجة، ولكن لم تكتمل المعالجة. قد يتم تنفيذ الطلب في النهاية أو لا يتم، حيث قد يتم رفضه عند حدوث المعالجة الفعلية.

المعلومات الوصفية المُعادة هي من نسخة محلية أو طرف ثالث، وليس من الخادم الأصلي، وقد تكون غير صحيحة. باستثناء هذه الحالة المحددة، يُفضل استخدام استجابة 200 OK على هذا الرمز.

عالج الخادم الطلب بنجاح ولا يُرجع أي محتوى. مفيد للإجراءات التي لا تتطلب نص استجابة، مثل طلب DELETE.

عالج الخادم الطلب بنجاح، ويطلب من مقدم الطلب إعادة تعيين عرض المستند الخاص به، ولا يُرجع أي محتوى. غالبًا ما يُستخدم بعد إرسال نموذج لمسح حقول النموذج لإدخال جديد.

يقوم الخادم بتسليم جزء فقط من المورد (خدمة البايت) بسبب رأس النطاق (Range) الذي أرسله العميل. يُستخدم رأس النطاق بواسطة أدوات مثل wget لتمكين استئناف التنزيلات المتقطعة، أو تقسيم التنزيل إلى تدفقات متزامنة متعددة.

WebDAV؛ ينقل معلومات حول موارد متعددة، للحالات التي قد تكون فيها رموز حالة متعددة مناسبة. النص الأساسي هو رسالة XML.

WebDAV؛ يُستخدم داخل عنصر استجابة <dav:propstat> لتجنب تعداد الأعضاء الداخليين لروابط متعددة لنفس المجموعة بشكل متكرر. تم بالفعل تعداد أعضاء الرابط في رد سابق.

لبى الخادم طلب GET للمورد، والاستجابة هي تمثيل لنتيجة واحد أو أكثر من معالجات المثيل المطبقة على المثيل الحالي. (RFC 3229)

يشير إلى خيارات متعددة للمورد يمكن للعميل الاختيار من بينها (مثل تنسيقات فيديو مختلفة، قائمة ملفات بامتدادات مختلفة). قد يتضمن الخادم رأس الموقع (Location) مع خيار مفضل.

يجب توجيه هذا الطلب وجميع الطلبات المستقبلية إلى URI المحدد. ستقوم محركات البحث بتحديث روابطها إلى المورد (في 'لغة السيو'، يُقال إن 'عصير الرابط' يتم إرساله إلى عنوان URL الجديد).

يعني رمز الاستجابة هذا أن URI المورد المطلوب قد تم تغييره مؤقتًا. قد يتم إجراء تغييرات أخرى على URI في المستقبل. لذلك، يجب على العميل استخدام نفس URI هذا في الطلبات المستقبلية.

أرسل الخادم هذه الاستجابة لتوجيه العميل للحصول على المورد المطلوب في URI آخر باستخدام طلب GET. يُستخدم عادةً بعد عملية POST/PUT لمنع تحديث الصفحة من إعادة إرسال النموذج.

يشير إلى أن المورد لم يتم تعديله منذ الإصدار المحدد بواسطة رؤوس الطلب If-Modified-Since أو If-None-Match. في مثل هذه الحالة، ليست هناك حاجة لإعادة إرسال المورد لأن العميل لا يزال لديه نسخة تم تنزيلها مسبقًا.

مهمل. المورد المطلوب متاح فقط من خلال وكيل، يتم توفير عنوانه في الاستجابة. العديد من عملاء HTTP (مثل Mozilla Firefox و Internet Explorer) لا يتعاملون بشكل صحيح مع الاستجابات بهذا الرمز، لأسباب أمنية في المقام الأول.

يرسل الخادم هذه الاستجابة لتوجيه العميل للحصول على المورد المطلوب في URI آخر بنفس الطريقة التي استخدمت في الطلب السابق. هذا له نفس دلالات رمز استجابة HTTP 302 Found، باستثناء أنه يجب ألا يغير وكيل المستخدم طريقة HTTP المستخدمة.

يقع المورد الآن بشكل دائم في URI آخر، محدد بواسطة رأس استجابة HTTP Location:. هذا له نفس دلالات رمز استجابة HTTP 301 Moved Permanently، باستثناء أنه يجب ألا يغير وكيل المستخدم طريقة HTTP المستخدمة: إذا تم استخدام POST في الطلب الأول، فيجب استخدام POST في الطلب الثاني.

لا يمكن للخادم أو لن يعالج الطلب بسبب خطأ واضح من جانب العميل (مثل بناء جملة طلب مشوه، أو تأطير رسالة طلب غير صالح، أو توجيه طلب خادع).

المصادقة مطلوبة وفشلت أو لم يتم توفيرها بعد. يجب أن تتضمن الاستجابة حقل رأس WWW-Authenticate يحتوي على تحدٍ ينطبق على المورد المطلوب. يُستخدم أحيانًا لـ 'فشل التفويض' ولكن 403 أكثر ملاءمة.

محجوز للاستخدام المستقبلي. كان القصد الأصلي أن هذا الرمز قد يُستخدم كجزء من شكل ما من أشكال النقد الرقمي أو مخطط المدفوعات الصغيرة، ولكن هذا لم يحدث بعد، وهذا الرمز غير مستخدم على نطاق واسع.

كان الطلب صالحًا، لكن الخادم يرفض الإجراء. قد لا يمتلك المستخدم الأذونات اللازمة للمورد، أو قد يحتاج إلى حساب من نوع ما.

تعذر العثور على المورد المطلوب ولكن قد يكون متاحًا في المستقبل. الطلبات اللاحقة من قبل العميل مسموح بها. غالبًا ما يُستخدم عندما لا يرغب الخادم في الكشف بالضبط عن سبب رفض الطلب، أو عندما لا تكون هناك استجابة أخرى قابلة للتطبيق.

طريقة الطلب غير مدعومة للمورد المطلوب؛ على سبيل المثال، طلب GET على نموذج يتطلب تقديم البيانات عبر POST، أو طلب PUT على مورد للقراءة فقط.

المورد المطلوب قادر فقط على إنشاء محتوى غير مقبول وفقًا لرؤوس Accept المرسلة في الطلب. على سبيل المثال، طلب العميل XML، لكن الخادم لا يمكنه توفير سوى JSON.

يجب على العميل أولاً مصادقة نفسه مع الوكيل. يجب أن يرسل الوكيل حقل رأس Proxy-Authenticate يحتوي على تحدٍ ينطبق على الوكيل للمورد المطلوب.

انتهت مهلة الخادم أثناء انتظار الطلب. وفقًا لمواصفات HTTP: 'لم يُنشئ العميل طلبًا خلال الوقت الذي كان الخادم مستعدًا للانتظار فيه. يجوز للعميل تكرار الطلب دون تعديلات في أي وقت لاحق.'

يشير إلى أنه لا يمكن معالجة الطلب بسبب تعارض في الحالة الحالية للمورد، مثل تعارض التعديل بين تحديثات متزامنة متعددة.

يشير إلى أن المورد المطلوب لم يعد متاحًا ولن يكون متاحًا مرة أخرى. يجب استخدام هذا عندما يتم إزالة مورد عن قصد ويجب تطهير المورد. عند تلقي رمز الحالة 410، يجب ألا يطلب العميل المورد في المستقبل.

لم يحدد الطلب طول محتواه، وهو مطلوب من قبل المورد المطلوب. لن يقبل الخادم الطلب بدون رأس Content-Length صالح.

لا يفي الخادم بأحد الشروط المسبقة التي وضعها مقدم الطلب على حقول رأس الطلب. غالبًا ما يُستخدم هذا مع طلبات GET الشرطية (باستخدام رؤوس If-Match أو If-Unmodified-Since).

الطلب أكبر مما يرغب الخادم أو يستطيع معالجته. كان يُسمى سابقًا 'كيان الطلب كبير جدًا'.

كان URI المقدم طويلاً جدًا بحيث لا يمكن للخادم معالجته. غالبًا ما يكون نتيجة ترميز الكثير من البيانات كسلسلة استعلام لطلب GET، وفي هذه الحالة يجب تحويله إلى طلب POST. كان يُسمى سابقًا 'Request-URI طويل جدًا'.

يحتوي كيان الطلب على نوع وسائط لا يدعمه الخادم أو المورد. على سبيل المثال، يقوم العميل بتحميل صورة كـ image/svg+xml، لكن الخادم يتطلب أن تستخدم الصور تنسيقًا مختلفًا.

طلب العميل جزءًا من الملف (خدمة البايت)، لكن الخادم لا يمكنه توفير هذا الجزء. على سبيل المثال، إذا طلب العميل جزءًا من الملف يقع خارج نهاية الملف. كان يُسمى سابقًا 'النطاق المطلوب غير قابل للتحقيق'.

لا يمكن للخادم تلبية متطلبات حقل رأس طلب Expect. أرسل العميل رأس Expect (مثل Expect: 100-continue) لا يمكن للخادم تلبيته.

تم تعريف هذا الرمز في عام 1998 كنكتة كذبة أبريل في RFC 2324، بروتوكول التحكم في إبريق القهوة عبر النص التشعبي (HTCPCP/1.0)، ولا يُتوقع أن يتم تنفيذه بواسطة خوادم HTTP الفعلية. ومع ذلك، يُستخدم أحيانًا كـ 'بيضة عيد الفصح'.

تم توجيه الطلب إلى خادم غير قادر على إنتاج استجابة. يمكن إرسال هذا بواسطة خادم غير مهيأ لإنتاج استجابات لمجموعة المخطط والسلطة المدرجة في URI الطلب.

WebDAV؛ كان الطلب جيد التكوين ولكنه لم يتمكن من المتابعة بسبب أخطاء دلالية. على سبيل المثال، يحتوي نص طلب XML على تعليمات XML جيدة التكوين (أي صحيحة نحويًا)، ولكنها خاطئة دلاليًا.

WebDAV؛ المورد الذي يتم الوصول إليه مقفل. هذا يعني أن مورد المصدر أو الوجهة لطريقة ما مقفل.

WebDAV؛ فشل الطلب لأنه اعتمد على طلب آخر وفشل هذا الطلب (على سبيل المثال، PROPPATCH مع PROPFIND فشل).

يجب على العميل التبديل إلى بروتوكول مختلف مثل TLS/1.0، المحدد في حقل رأس Upgrade. يرسل الخادم رأس Upgrade مع هذه الاستجابة للإشارة إلى البروتوكول (البروتوكولات) المطلوبة.

يتطلب الخادم الأصلي أن يكون الطلب شرطيًا. يهدف إلى منع مشكلة 'التحديث المفقود'، حيث يحصل العميل على حالة مورد، ويعدلها، ويعيدها إلى الخادم، بينما في هذه الأثناء قام طرف ثالث بتعديل الحالة على الخادم، مما يؤدي إلى تعارض.

أرسل المستخدم عددًا كبيرًا جدًا من الطلبات في فترة زمنية معينة ('تحديد المعدل'). يجب أن تتضمن تمثيلات الاستجابة تفاصيل تشرح الحالة، وقد تتضمن رأس Retry-After يشير إلى المدة التي يجب انتظارها قبل تقديم طلب جديد.

الخادم غير راغب في معالجة الطلب لأن حقول رأسه كبيرة جدًا. يجوز إعادة تقديم الطلب بعد تقليل حجم حقول رأس الطلب.

يرفض الخادم الوصول إلى المورد نتيجة لطلب قانوني. قد يكون هذا رقابة حكومية أو أمر محكمة.

رسالة خطأ عامة، تُعطى عند مواجهة حالة غير متوقعة وعدم وجود رسالة أكثر تحديدًا مناسبة. هذا خطأ من جانب الخادم 'شامل'.

إما أن الخادم لا يتعرف على طريقة الطلب، أو أنه يفتقر إلى القدرة على تلبية الطلب. عادة ما يعني هذا التوفر المستقبلي (مثل ميزة جديدة لواجهة برمجة تطبيقات خدمة الويب).

كان الخادم يعمل كبوابة أو وكيل وتلقى استجابة غير صالحة من الخادم الأصلي (upstream server) الذي وصل إليه في محاولة لتلبية الطلب.

الخادم غير متاح حاليًا (لأنه محمّل بشكل زائد أو معطل للصيانة). بشكل عام، هذه حالة مؤقتة. قد يتم تضمين رأس Retry-After لاقتراح تأخير.

كان الخادم يعمل كبوابة أو وكيل ولم يتلق استجابة في الوقت المناسب من الخادم الأصلي أو خادم مساعد آخر احتاج إلى الوصول إليه لإكمال الطلب.

لا يدعم الخادم إصدار بروتوكول HTTP المستخدم في الطلب. يجب أن تحتوي الاستجابة على كيان يصف سبب عدم دعم هذا الإصدار وما هي البروتوكولات الأخرى التي يدعمها هذا الخادم.

ينتج عن تفاوض المحتوى الشفاف للطلب مرجع دائري. تم تكوين مورد البديل المختار للمشاركة في تفاوض المحتوى الشفاف بنفسه، وبالتالي فهو ليس نقطة نهاية مناسبة في عملية التفاوض.

WebDAV؛ الخادم غير قادر على تخزين التمثيل اللازم لإكمال الطلب. تعتبر هذه الحالة مؤقتة.

WebDAV؛ اكتشف الخادم حلقة لا نهائية أثناء معالجة الطلب (تم إرسالها بدلاً من 208 تم الإبلاغ عنه بالفعل). هذا يشير إلى فشل العملية بأكملها.

مطلوب تمديدات إضافية للطلب حتى يتمكن الخادم من تلبيته. يتطلب الطلب امتدادًا إلزاميًا غير مدعوم من قبل الخادم.

يحتاج العميل إلى المصادقة للوصول إلى الشبكة. مخصص للاستخدام بواسطة وكلاء الاعتراض المستخدمين للتحكم في الوصول إلى الشبكة (مثل 'البوابات المقيدة' المستخدمة لطلب الموافقة على شروط الخدمة قبل منح الوصول الكامل إلى الإنترنت عبر نقطة اتصال Wi-Fi).