http دليل أكواد حالة HTTP star

لماذا تُجمَّع أكواد الحالة بحسب الرقم الأول

كل كود حالة HTTP رقم من ثلاثة أرقام، والرقم الأول وحده يخبر العميل بالفئة العامة للاستجابة قبل أن يقرأ باقيها حتى — وهو خيار تصميمي متأصل في HTTP منذ أولى مواصفاته واستمر لاحقًا، ورسّمه اليوم RFC 9110، الوثيقة التي وحّدت سلسلة RFC 7230-7235 الأقدم وحلّت محلها لتُعرِّف دلالات HTTP بمعزل عن أي إصدار بروتوكول واحد (يشترك HTTP/1.1 وHTTP/2 وHTTP/3 جميعًا في معاني أكواد الحالة نفسها). 1xx (إعلامي) يعني أن الطلب استُلم وفُهم والمعالجة مستمرة — وهذه استجابات مؤقتة لا ينبغي للعميل معاملتها كنهائية. 2xx (نجاح) يعني أن الطلب استُلم وفُهم وقُبل. 3xx (إعادة توجيه) يعني أن إجراءً إضافيًا مطلوب لإكمال الطلب، عادةً جلب رابط مختلف. 4xx (خطأ من العميل) يعني أن الطلب، كما أُرسل، يحتوي مشكلة تسبب بها العميل — بنية سيئة، مصادقة مفقودة، مورد غير موجود. 5xx (خطأ من الخادم) يعني أن الطلب كان صالحًا على ما يبدو لكن الخادم فشل في تنفيذه. هذا النظام القائم على الرقم الأول يعني أن عميلًا لا يعرف سوى الرقم "4" ولا شيء آخر عن كود محدد لا يزال يعرف، بشكل صحيح، أن شيئًا في طلبه هو ذاته يحتاج إصلاحًا لا إعادة محاولة مطابقة — وهذا السلوك الاحتياطي هو بالضبط سبب اشتراط المعيار له.

يُقسِّم الرقمان الثاني والثالث كل فئة إلى معانٍ محددة وموثَّقة، ويُتوقَّع من العميل الرجوع إلى سلوك الفئة العامة لأي كود لا يتعرف عليه تحديدًا — وهذا سبب بقاء أكواد غامضة أو أحدث مثل 226 أو 508 آمنة للتعامل معها بشكل صحيح تقريبيًا حتى من قِبَل برمجيات أقدم دون دعم صريح. الأكواد أيضًا لا تُخترَع بحرية: يحافظ على السجل الكامل هيئة IANA (سلطة الأرقام المخصصة على الإنترنت) بالضبط حتى لا يعني "599" أو "250" شيئين مختلفين على خادمين مختلفين — كل كود قيد الاستخدام الفعلي يُرجَع إلى RFC محدد يُعرِّف دلالاته الدقيقة، ويوسِّع عدد منها مواصفة HTTP/1.1 الأصلية لبروتوكولات معينة، أبرزها WebDAV (RFC 4918)، وهو مصدر أكواد 207 و208 و422 و423 و424 وَ507/508 في هذه الصفحة.

كودان يستحقان معرفة دقيقة: 404 مقابل 410

من أكثر الأكواد التباسًا 404 غير موجود وَ410 مُزال نهائيًا، والفرق بينهما ليس شكليًا — فهو يُغيِّر كيفية تصرف محرك بحث ومتصفح. 404 غامض عمدًا: لا تملك الخادم أي معلومة عمّا إذا كان المورد موجودًا يومًا ما على ذلك الرابط، أو قد يعود، أو أن الرابط كُتب خطأً ببساطة. 410 عبارة أقوى ومتعمَّدة: كان المورد موجودًا فعليًا في ذلك الرابط بالضبط وأُزيل عمدًا وبشكل نهائي، دون عنوان إعادة توجيه — يوصي RFC 9110 صراحةً بـ410 تحديدًا لحالة "من المرجح أن يكون الوضع دائمًا" هذه حيث يُقلِّل 404 من درجة اليقين. تعامل محركات البحث هذا الأمر بشكل مختلف عمليًا: عادةً ما يُحذَف رابط يُعيد 404 متكررة من الفهرس فقط بعد إعادة زحفه عدة مرات على مدى فترة طويلة تحسبًا لعودته، بينما يُشير 410 إلى إزالة متعمَّدة وتتصرف محركات البحث عمومًا بناءً عليه بشكل أسرع، فتُخرِج الصفحة من الفهرس أبكر لأن الخادم أكّد صراحةً أنها لن تعود. استخدام 410 بشكل صحيح عند التقاعد النهائي لصفحة ما — بدلًا من الاعتماد الافتراضي على 404 لكل شيء — رافعة تقنية صغيرة لكن حقيقية لتحسين محركات البحث.

• 301 مقابل 302 مقابل 307 مقابل 308: يعني كل من 301 و308 "نُقل بشكل دائم"، بينما يعني كل من 302 و307 "نُقل مؤقتًا" — قُدِّم الزوج الأحدث 307/308 خصيصًا لضمان الحفاظ على طريقة الطلب وجسمه عند إعادة التوجيه (يبقى POST كـPOST)، لأن سلوك المتصفحات التاريخي الشائع كان يحوِّل إعادة توجيهات 301/302 بصمت إلى GET، ما كان يُعطِّل إعادة إرسال النماذج بطرق تُصلحها الأكواد الأحدث.
• 401 مقابل 403: يعني 401 غير مصرَّح تقنيًا "لم تُوثَّق هويتك — سجّل الدخول"، رغم الاسم المُربِك؛ ويعني 403 ممنوع "هويتك معروفة، لكن لا يُسمح لك بالوصول إلى هذا"، وهو تمييز تُبهمه واجهات برمجية كثيرة عمليًا لكن المواصفة تُبقيه منفصلًا بوضوح.
• 429 طلبات كثيرة جدًا (RFC 6585) هو استجابة تحديد المعدل القياسية، ويقترن عادةً برأس Retry-After يخبر العميل بالضبط كم يجب أن ينتظر قبل إعادة المحاولة.
• أكواد 1xx نادرًا ما تُرى مباشرةً لأن معظم مكتبات عميل HTTP تتعامل معها بشفافية قبل أن يرى كود تطبيقك استجابة أصلًا — 100 استمرار، على سبيل المثال، يتيح للعميل التحقق مما إذا كان جسم طلب كبير يستحق الإرسال أصلًا قبل إرساله.