رموز الحالة (status codes): ما الذي يقوله الخادم في ثلاثة أرقام

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

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

الرقم الأول يقول نوع الجواب، والرقمان بعده يفصلانه

يتكون رمز الحالة من ثلاثة أرقام تتراوح قيمتها القياسية دائما بين 100 و599. وتتفاوت هذه الخانات في وظيفتها التعليمية والعملية: فالرقم الأول بمفرده يحدد النوع العام للجواب، وهو ما يطلق عليه اسم فئة رمز الحالة (status code class)، بينما تنحصر وظيفة الرقمين التاليين في التمييز بين الحالات الفرعية المتنوعة داخل نطاق الفئة نفسها.

وتتوزع الردود على خمس فئات فقط، تبعا للرقم الأول الذي لا يتعدى القيم من 1 إلى 5:

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

تمنحك هذه البنية نصف التشخيص من النظرة الأولى؛ فبمجرد رصد رمز يبدأ بالرقم 4 في لوحة أدوات الشبكة، تدرك مسبقا أن الخادم رفض معالجة الطلب لوجود إشكال في بنائه أو بياناته لا لعطل في الخادم، مما يوجه جهد الفحص إلى صياغة الطلب نفسه. وعلى النقيض من ذلك، يوضح الرمز الذي يبدأ بالرقم 5 أن الطلب وصل مستوفيا للشروط في ظاهره، وأن مصدر العائق يقع في المنظومة الخلفية المقابلة.

رمز لم تره من قبل: قاعدة x00

لا تشكل رموز الحالة قائمة محصورة نهائيا؛ إذ تتيح مواصفة البروتوكول استحداث رموز جديدة عبر اعتمادها في مرجع رسمي يعرف باسم سجل رموز حالة HTTP لدى هيئة أرقام الإنترنت المخصصة (Internet Assigned Numbers Authority, IANA). وبناء على هذه المرونة، قد يتلقى تطبيقك يوما رمزا لم يكن واردا أثناء كتابة شفرته البرمجية.

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

ويمتد هذا المبدأ ليشمل القيم الرقمية الشاذة: ففي حال استقبال رمز يقع خارج النطاق القياسي 100–599، تفرض المواصفة على العميل معالجته باعتباره عطلا داخليا من فئة 5xx. وتستخدم بعض المكتبات البرمجية أرقاما ثلاثية تتجاوز 599 للإشارة إلى أخطاء داخلية في بيئتها التشغيلية، غير أن هذه الأرقام لا تصنف رموز حالة قياسية ولا يصح تمريرها عبر شبكة الاتصال.

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

2xx: نجاح الطلب، لكن أي نجاح؟

تعبر الفئة 2xx عن تسلم الخادم للطلب واستيعابه وقبوله للمعالجة. إلا أن النجاح يتخذ أنماطا متعددة، خصص لكل منها رمز مستقل يعكس أثرا عمليا يختلف لدى طرف العميل. وتعتمد أمثلة هذا الدرس على موقع مدونة يقع على النطاق blog.example.com، يتيح مسارا لقائمة التعليقات عند العنوان /articles/http-methods/comments، ومسارا لتعليق مستقل عند العنوان /comments/17.

200 (OK) يمثل الاستجابة القياسية للنجاح؛ فحين يطلب العميل قراءة قائمة التعليقات ويجيب الخادم بهذا الرمز، يتضمن جسم الرسالة المعادة المحتوى المطلوب كاملا. وتبرز هذه القيمة في النسبة الكبرى من سجلات لوحة الشبكة اليومية.

201 (Created) يفيد بإتمام معالجة الطلب ونجاحه في توليد مورد رقمي جديد لم يكن موجودا مسبقا. ويعد هذا الرد الاستجابة المعتادة لطلب نشر تعليق جديد:

HTTP/1.1 201 Created
Location: /comments/17
Content-Type: application/json

{"id":17,"name":"Sara","text":"Useful lesson"}

• السطر الأول يحمل الرمز 201 ليعلن إتمام إنشاء المورد.
• السطر الثاني يتضمن ترويسة الموقع Location، وتحمل قيمتها رابط العنوان الفريد للمورد الجديد. وتبرز أهمية هذه الترويسة لكون العميل يوجه طلبه في الأصل نحو مسار تجميعي عام لقائمة التعليقات، دون علم مسبق بالمعرف الذي سيخصصه الخادم لهذا التعليق تحديدا.
• السطر الثالث وجسم الرسالة يوضحان طبيعة البيانات المعادة؛ إذ تبين الترويسة اعتماد صيغة JSON، في حين يحمل الجسم نسخة من بيانات التعليق المنشأ، وهو إجراء تتبعه معظم الخوادم لتجنيب العميل إرسال طلب استعلام إضافي.

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

202 (Accepted) يحمل دلالة تشغيلية مغايرة: يفيد بقبول الطلب دون إتمام تنفيذه الفعلي بعد. ومثاله أن يطلب مدير النظام تصدير أرشيف التعليقات بالكامل في ملف مضغوط، فتدرج الخدمة هذه المهمة ضمن رتل معالجة مجدول للتنفيذ لاحقا. وتنص المواصفة بوضوح على أن هذا القبول غير ملزم بإكمال نهائي؛ فقد تلغى العملية لاحقا أو تتعثر برمجيا، ولا يملك بروتوكول HTTP آلية تتيح للخادم دفع رمز حالة ثان للعميل بعد فراغه من العمل. ومن هنا جرى العرف أن يرفق الخادم في جسم الرد رابطا يمكن للعميل من خلاله تتبع مرحلة تقدم المعالجة.

204 (No Content) يعني اكتمال تنفيذ الطلب بنجاح تام، مع انتفاء الحاجة إلى إعادة أي بيانات في جسم الرد. وبناء على ذلك تخلو الرسالة من أي جسم، وتنتهي بنيتها بانتهاء سطر الترويسات مباشرة. ويلائم هذا السلوك طلبات حفظ التعديلات السريعة ضمن المحررات المدمجة، إذ يواصل المستخدم تفاعله في الصفحة ذاتها دون حاجة لإعادة تحميل واجهتها. وتستطيع معاينة هذا السلوك واقعيا عبر خدمة التجربة والاختبار httpbin:

curl -i https://httpbin.org/status/204

HTTP/2 204
date: Tue, 22 Sep 2026 04:28:52 GMT
server: gunicorn/19.9.0

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

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

3xx: الجواب لم يكتمل، وعلى العميل خطوة أخرى

توضح الفئة 3xx أن اكتمال الغاية من الطلب يقتضي اتخاذ إجراء إضافي من جانب برنامج العميل. ورغم أن التسمية الشائعة لهذه الفئة هي «إعادة التوجيه»، إلا أنها تصف النمط الأوسع انتشارا لا كامل الحالات المندرجة تحتها.

يتمثل النمط الأول في إعادة التوجيه بمعناها المألوف: استقرار المورد المطلوب في مسار مختلف، حيث يضمن الخادم ذلك الرابط الجديد داخل ترويسة Location، مستخدما أحد الرموز 301 أو 302 أو 307 أو 308. يتولى برنامج العميل قراءة الرابط ومتابعته بإرسال طلب تعقيبي مستقل، وهو إجراء تنفذه المتصفحات تلقائيا في الخلفية دون استيقاف المستخدم. وتفرد هذه الدورة درسا مستقلا لبحث الفروق التشغيلية بين تلك الرموز الأربعة، وتحديد الحالات التي تحافظ على طريقة الطلب الأصلية وتلك التي تحولها.

أما النمط الثاني فلا يترتب عليه انتقال إلى مسار بديل، ويجسده الرمز 304 (Not Modified). يعلن هذا الرمز أن النسخة المخبأة المخزنة محليا لدى العميل ما تزال مطابقة لما لدى الخادم وصالحة للاستخدام المباشر دون حاجة لتنزيل نسخة جديدة. وبناء على ذلك يجرد الرد من جسم الرسالة، محققا الغاية الأساسية منه: تقليل استهلاك البيانات وتوفير وقت النقل بالاكتفاء بإشعار يؤكد عدم حدوث تعديل. ولا يصدر هذا الرد تلقائيا، بل يشكل جوابا على استعلام مشروط وجهه العميل مسبقا للتحقق من صلاحية نسخته، وهو مسار مفصل في درس التخزين المؤقت.

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

4xx: الخلل في الطلب كما رآه الخادم

تفيد الفئة 4xx بأن الخلل يعود في ظاهره إلى طرف العميل. وتستخدم المواصفة عبارة «فيما يبدو» بدقة مقصودة، لكون التوصيف يمثل تقييم الخادم للطلب الوارد، وليس تقريرا بحقيقة مطلقة حول الطرف المخطئ. وتوصي المواصفات القياسية بأن يضمن الخادم جسم استجابته شرحا لطبيعة التعثر، وهو ما يفسر ظهور الرسائل التوضيحية داخل صفحات الخطأ.

وتشمل هذه الفئة مجموعة من الرموز الأكثر تكرارا في التطوير اليومي:

• 400 (Bad Request): عجز الخادم عن فهم الطلب أو امتناعه عن معالجته نتيجة عيب في صياغته التركيبية، كوجود خلل في بنية البيانات.
• 404 (Not Found): عدم عثور الخادم على تمثيل حالي للمورد المستهدف عند ذلك العنوان، أو رغبته في التكتم على وجوده.
• 405 (Method Not Allowed): تعرف الخادم على طريقة الطلب المستخدمة، مع حظر استخدامها على هذا المورد بعينه، ويلزمه المعيار هنا بإرفاق ترويسة Allow متضمنة الطرق المسموح بها.
• 409 (Conflict): تعارض تنفيذ الطلب مع الحالة الراهنة للمورد، كما يحدث عند إرسال عميلين تعديلات متزامنة ومتناقضة على التعليق ذاته؛ ومقصد الرمز تمكين المستخدم من فض النزاع ثم إعادة الإرسال.
• 429 (Too Many Requests): تجاوز العميل لمعدل الطلبات المسموح به خلال فترة زمنية محددة، وهو ما يعرف بآلية تحديد المعدل (rate limiting)، وقد يرفق الخادم معه ترويسة Retry-After لتحديد موعد إعادة المحاولة.

وهناك رموز أكثر تخصصا لحالات مقيدة، مثل 413 لتجاوز حجم جسم الطلب للحدود المقبولة، و414 لتخطي الرابط الطول المسموح به، و415 لإرسال محتوى بصيغة لا تدعمها معالجة المورد. ولا يتطلب العمل حفظ كل هذه الحالات تفصيلا؛ إذ يكفي ربطها بفئة 4xx لمعرفة أن مراجعة المعطيات تبدأ من جانب الطلب نفسه.

401 و403: لم تثبت هويتك، أم أثبتها ولا يسمح لك؟

يعد هذان الcodeان من أكثر الرموز تداخلا في الاستخدام العملي، لأن كليهما ينتهي بمنع الوصول إلى المحتوى، غير أن المنع ينبني في كل منهما على مسوغ تقني مختلف ويفرض سلوكا تعويضيا مستقلا.

يستند الفارق الجوهري بينهما إلى مفهومين أمنيين متتابعين: الأول هو التحقق من هوية صاحب الطلب ويسمى إثبات الهوية أو المصادقة (authentication)، والثاني هو التأكد من امتلاك تلك الهوية بعد ثبوتها الصلاحيات الكافية للتعامل مع هذا المورد ويسمى التخويل أو الإذن (authorization). الأول معني بالسؤال: «من أنت؟»، والثاني معني بالسؤال: «هل تملك حق الدخول؟».

401 (Unauthorized) يفيد بتعذر تنفيذ العملية بسبب افتقار الطلب إلى بيانات اعتماد (credentials) صحيحة تؤكد الهوية. وانطلاقا من هذا القيد، تلزم المواصفة الخادم بإرفاق ترويسة WWW-Authenticate مع كل رد يحمل الرمز 401، متضمنة آلية واحدة على الأقل من آليات المصادقة المعتمدة لديه. وتتضح هذه المعاملة عبر تجربة عنوان مؤمن بكلمة مرور لدى خدمة httpbin:

curl -i https://httpbin.org/basic-auth/sara/secret

HTTP/2 401
date: Tue, 22 Sep 2026 04:28:54 GMT
content-length: 0
server: gunicorn/19.9.0
www-authenticate: Basic realm="Fake Realm"

صدر الرمز 401 نتيجة خلو الطلب من بيانات الاعتماد، واقترنت به ترويسة www-authenticate التزاما بالمواصفة القياسية لتبين نمط التحقق المقبول في هذا النطاق، وهي أنماط يختص ببيانها وتفصيل آليات إرسالها درس مستقل ضمن الدورة.

403 (Forbidden) يقدم مدلولا مغايرا: فهم الخادم طبيعة الطلب بدقة لكنه يرفض تنفيذه؛ فإذا تضمن الطلب بيانات اعتماد مسبقة، فالخادم يراها قاصرة عن منح صاحبها حق الوصول إلى المورد المستهدف. وتوصي المواصفة برنامج العميل بتجنب تكرار إرسال الطلب تلقائيا بالاعتماد على البيانات نفسها دون تعديل، إذ لن يؤدي ذلك إلى أي تغيير في النتيجة، في حين يسوغ له تكرار المحاولة باستخدام بيانات أخرى، مع الأخذ بالحسبان أن الحظر قد يستند إلى قيود أخرى لا ترتبط بالهوية كالحجب الجغرافي أو قيود الشبكة.

تختصر المقارنة في صيغة عملية: الرمز 401 يطالبك بإثبات هويتك أولا للمضي قدما، بينما يقرر الرمز 403 إدراك النظام لهويتك مع رفض تمكينها من المورد. فزيارة لوحة إدارة الموقع دون تسجيل مسبق تثمر الرمز 401، في حين تنتهي محاولة الوصول إليها بحساب قارئ عادي إلى استقبال الرمز 403.

وتجيز المواصفة للخادم استخدام الرمز 404 عوضا عن 403 إذا استهدفت سياسته الأمنية إخفاء وجود المورد كليا؛ ولهذا السبب يعيد موقع GitHub إشعارا يفيد بعدم وجود المستودع عند محاولة فتح مستودع خاص لا تملك إذنا بدخوله بدلا من إعلان المنع، وهو تدبير متعمد توثقه إرشادات المنصة الرسمية لتجنب الإقرار الضمني بوجود المستودع للعموم.

404 و410: غير موجود، أم أزيل عمدا؟

يتفق هذان الcodeان في إعلان غياب المورد عن المسار المستهدف، غير أن الثاني يتميز بتقديم معلومة إضافية ترسم مآل هذا الغياب.

404 (Not Found) لا يحدد مستقبلا للمورد؛ فالخادم لم يعثر على تمثيل راهن للعنوان، دون بيان ما إذا كان هذا الاختفاء عارضا أو دائما، إذ يحتمل ظهور المورد لاحقا، مثلما يحتمل أن يكون العنوان قد كتب بصورة غير صحيحة من الأساس.

410 (Gone) يوضح سياقا أوسع: كان المورد مستقرا في هذا الموضع ثم أزيل عن قصد، والغالب أن هذا الحذف نهائي. وتحدد المواصفة الغاية الوظيفية من هذا التمايز: إبلاغ الأطراف المستلمة بأن عملية الحذف جرت عمدا، مما يقتضي من محركات البحث والعملاء إزالة الروابط الموجهة إلى هذا المسار. وتبرز فائدة هذا الرمز عند الرغبة في إخطار عناكب الفهرسة بإزالة صفحة معينة نهائيا دون تركها معلقة كعطل تقني طارئ.

تعتمد المفاضلة بينهما على معيار واضح: إذا ثبت لدى منظومة الخادم أن الاستبعاد نهائي فالأصل توظيف الرمز 410، أما إذا كان الأمر مجهولا أو افتقر النظام لآلية تتبع الحذف فالاختيار الافتراضي هو 404. ولا يلزم أي تطبيق برصد كل مدخل محذوف وتتبعه بالرمز 410، مما يفسر بقاء 404 الخيار الأكثر شيوعا للتعامل مع العناوين الغائبة.

400 و422: الرسالة مكسورة، أم محتواها مرفوض؟

يعتمد الخادم الرمز 400 (Bad Request) عندما يكمن الخلل في الهيئة التركيبية للطلب نفسه؛ ومثاله إرسال حمولة يفترض أنها من نوع JSON لكنها تفتقر لقوس إغلاق، مما يعجز الخادم عن تحليلها بنيويا:

POST /articles/http-methods/comments HTTP/1.1
Host: blog.example.com
Content-Type: application/json
Content-Length: 29

{"name":"Sara","text":"Useful

يوضح السطر الأول توجه العميل لنشر تعليق، وتعلن ترويسة Content-Type تنسيق المحتوى بصيغة JSON، في حين تسجل ترويسة Content-Length حجما قدره 29 بايتا. ورغم وصول كامل هذه البايتات على النحو المعلن، إلا أن صياغة النص مشوهة: فتح قوس وعلامة اقتباس دون إتمامهما. وبناء عليه يتوقف الخادم دون تقييم معنى التعليق، لعجزه عن تفكيك النص واستخراجه من الأصل.

في المقابل، يتدخل الرمز 422 (Unprocessable Content) في مرحلة تالية لتلك الخطوة: إذ تكون الصياغة مقروءة وتركيب البيانات متماسكا، لكن الخادم يعجز عن معالجة التعليمات الواردة فيه منطقيا. ومثاله استلام بيانات JSON سليمة البناء، لكن حقل التعليق ورد فارغا، أو تجاوز اسم الكاتب الحد الأقصى المعتمد في قواعد المدونة. فالرسالة استوفت شروط القراءة، والمحتوى هو الذي أخفق في استيفاء شروط المعالجة. وقد تصادف هذا الرمز تحت اسم Unprocessable Entity وهو الاسم القديم الذي ما تزال تتداوله بعض المكتبات، في حين اعتمدت المواصفة الحديثة اسم Unprocessable Content.

أما إذا كانت صيغة البيانات ذاتها غير مدعومة في النظام، كأن يرسل العميل مدخلات بتنسيق XML إلى واجهة لا تقبل سوى JSON، فالرمز الصحيح للحالة هو 415، وليس 400 ولا 422.

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

5xx: الخادم يعلن عجزه

تعلن الفئة 5xx إدراك الخادم لوقوع عطل لديه أو عجزه عن إتمام ما طلب منه، مع إقراره بسلامة الطلب الوارد في ظاهره؛ فهي المساحة المخصصة لإقرار الخادم بمسؤوليته عن التعثر.

500 (Internal Server Error) يمثل التوصيف الشامل لأي عطل برمجي غير متوقع يحول دون إتمام الطلب، وهو ما يظهر عادة عند اعتراض استثناء برمجي غير معالج داخل بيئة التشغيل، ولا يحمل تفصيلا لأسباب الفشل لكونه يعبر بإيجاز عن تعثر خارج عن الحسبان.

501 (Not Implemented) يفيد بعدم دعم الخادم للوظيفة المطلوبة كليا، ويصلح ردا عند ورود طريقة طلب مجهولة لا يملك النظام بنية لدعمها في أي مسار. ويحسن تمييزه عن الرمز 405؛ ففي حالة 405 يدرك الخادم ماهية الطريقة لكنه يحظرها على مورد معين، أما في 501 فالتقنية ذاتها غائبة عن قدراته التشغيلية في سائر مرافقه.

يشير الرمزان 502 (Bad Gateway) و504 (Gateway Timeout) إلى معمارية الخوادم الوسيطة؛ فالخادم الذي يستقبل الطلب ليس بالضرورة هو الذي ينفذه أو يملك بياناته، بل كثيرا ما تقف في الواجهة خوادم وسيطة تتولى توجيه الحركة إلى أنظمة خلفية، وهي وسائط تستعرض الدورة أنواعها ومهامها في درس مخصص. فإذا ورد إلى الخادم الأمامي رد غير صالح من الخادم الخلفي، أعاد للعميل الرمز 502، أما إذا انقضت المهلة الزمنية المحددة للانتظار دون وصول أي رد، فحينئذ يعاد الرمز 504.

503 (Service Unavailable) يعلن عجز المنظومة المؤقت عن تقديم الخدمة، لضغط تشغيلي فائق أو لوجود أعمال صيانة مجدولة. ويملك الخادم حينها خيار إرفاق ترويسة Retry-After لاقتراح المدة الزمنية المناسبة لمعاودة الطلب:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

يتضمن السطر الأول إشعار الحالة 503، بينما يحدد السطر الثاني ضرورة انتظار العميل مدة مئة وعشرين ثانية قبل استئناف الاتصال. وتدعم هذه الترويسة طريقتين للتمثيل: إدراج عدد الثواني كالمثال أعلاه، أو تحديد تاريخ وتوقيت محددين.

وتتجلى القيمة التشخيصية لتلك الفروق في توجيه الفحص قبل مطالعة سجلات النظام: فالرمز 500 يوجه الأنظار إلى الشفرة البرمجية للتطبيق، و502 و504 يحددان موضع الخلل في الاتصال البيني أو تأخر الاستجابة بين الطبقات الخادمة، بينما يركز 503 المراجعة على سعة المنظومة وجداول الصيانة.

1xx: جواب مؤقت قبل الجواب النهائي

تختلف الفئة 1xx عن الفئات الأربع الأخرى في طبيعة دورها، فهي الأقل ظهورا في الاستخدام اليومي لأنها تقدم استجابة مرحلية لا تغلق دورة الطلب.

يقترن كل طلب بجواب نهائي واحد (final response) لا أكثر، ينتمي رمزه حتما إلى إحدى الفئات الأربع المتبقية، غير أن الخادم يملك صلاحية تصدير استجابة مؤقتة (interim response) أو أكثر تسبق الجواب الحاسم، وتندرج هذه الاستجابات وجوبا تحت الفئة 1xx. ولا تنهي الرسالة المؤقتة دورة المعالجة، بل تعمل كإشعار بتقدم العمل؛ ولهذا السبب تخلو تماما من أي جسم، وتنتهي بانتهاء سطر ترويساتها مباشرة.

ويعد 100 (Continue) أشهر رموزها، وتكمن فائدته في تفادي الهدر بنقل حمولات ضخمة دون جدوى؛ فعند عزم العميل على رفع ملف ذي حجم كبير، يقتصر أولا على إرسال ترويسات الطلب مرفقة بترويسة التوقع Expect وقيمتها 100-continue، ممسكا عن دفع جسم الملف ريثما يتلقى موقفا مبدئيا. فإن أجاب الخادم بالرمز 100، باشر العميل ضخ باقي البيانات، أما إذا تبين للخادم من مطالعة الترويسات تعذر قبول الطلب، فإنه يعاجله بالرد برمز رفض مثل 401 أو 405، موفرا على الشبكة استهلاك سعة نقل ملف مقضي عليه بالرفض سلفا.

وينضم إلى هذه الفئة الرمز 101 الذي يفعل عند توافق الطرفين على الترقية لبروتوكول اتصال آخر فوق القناة المفتوحة ذاتها، والرمز 103 المعتمد لتمرير تلميحات مبكرة للعميل قبل استكمال تجهيز الرد الختامي؛ وتتناول الدورة تفاصيل الأول في سياق القنوات المستمرة، والثاني في محور تحسين الأداء.

ولما كانت النسخة القديمة HTTP/1.0 تفتقر إلى تعريف هذه الفئة كليا، فإن المواصفة تحظر إرسال أي رمز من فئة 1xx إلى عميل يتخاطب بهذا الإصدار. ولأن أدوات التطوير تركز افتراضيا على إظهار الجواب النهائي المستقر، فقد يمضي المطور سنوات في عمله دون أن يرصد رمزا من هذه الفئة عبر لوحة الشبكة.

الرموز التي تلقاها فعلا في جدول واحد

الرمز جواب تلتزم به البرمجيات

يمثل رمز الحالة عقدا تقنيا تترجمه البرمجيات إلى مسارات عمل تنفيذية، وتتعامل معه أدوات التطوير كمعلومة فاصلة لا مجرد سطر يعرض في واجهة الخطأ. فالمتصفح يستند إلى الرقم لتقرير ما إذا كان سيعرض المحتوى أو يتبع مسارا بديلا، وأداة الفحص curl تعد الرموز من 400 فصاعدا إخفاقا صريحا للطلب عند تمرير المعامل -f، وأنظمة الرصد والمراقبة تحتسب نسبة الردود التابعة لفئة 5xx كمعيار أساسي لتقييم سلامة الخدمات البرمجية.

وانطلاقا من هذه المركزية، فإن إقدام خادم على الرد بالرمز 200 مع إرفاق إشعار بالخطأ داخل جسم الرسالة ينتج عنه تضليل فوري لمختلف الأدوات التقنية؛ إذ تصنف لوحة الشبكة الاتصال على أنه ناجح، وتستبعد منظومة المراقبة واقعة التعطل من حساباتها، بينما يواصل تطبيق العميل مساره المعتاد بافتراض تمام العملية ما لم يتضمن شفرة استثنائية مخصصة لفحص تفاصيل البايتات الواردة. فالرقم وحده يشكل مرجع القرار للأدوات، وأي تناقض بين الرمز وحقيقة الواقع يوقع المنظومات البرمجية في تقييمات مضللة.

وفي المقابل، يظل رمز الحالة توصيفا لنتيجة المعالجة كما صنفها الخادم ضمن حدوده المنطقية، لا شهادة تفصيلية بكامل العمليات التحتية المرافقة. فالرمز 200 المصاحب لطلب حذف يفيد بأن الخادم نفذ منطق المعالجة المقرر لهذا الأمر بنجاح، دون أن يحمل أبعادا أعمق من ذلك. وتلك هي الرؤية التي تقرأ بها هذه المنظومة: ثلاثة أرقام تكفي لترسم لكل أداة عبر الشبكة مسارها اللاحق، دون أن تحكي لها تفاصيل ما جرى خلف الكواليس.

اختبر فهمك

ثمانية أسئلة قصيرة تغطي أفكار الدرس. اختر إجابة ثم اضغط «تحقق» لترى إن كانت صحيحة ولماذا. وفي آخر الاختبار تظهر نتيجتك، ومع كل سؤال أخطأت فيه زر يعيدك إلى القسم الذي يشرحه.