انتقل إلى محتوى الدرس
الدرس 46
دورة تكنولوجيا الويب

أكواد حالة HTTPHTTP Status Codes

أكواد حالة HTTP
أقسام الدرس
29
الأمثلة
55
اللغة
العربية
تاريخ النشر
المشاهدات
2,970
محتوى الدرس
في هذا الدرس 29تصفّح المواضيع

HTTP Status Codes أكواد حالة HTTP

تُعتبر أكواد الحالة HTTP status codes في بروتوكول HTTP أداة مهمة في التواصل بين الخادم والمستخدم عبر الإنترنت، حيث ترد الخوادم بهذه الأكواد على طلبات المستخدم user requests، تتألف الأكواد من ثلاثة أرقام يُحدد الرقم الأول منها فئة الاستجابة response التي تشير إلى التصنيف العام الذي يندرج تحته كود الحالة status code في بروتوكول HTTP، حيث تقدم كل فئة معلومات حول نوع الاستجابة response التي يقدمها الخادم للطلب.

على سبيل المثال، الأكواد التي تبدأ بالرقم 1 تشير إلى معلومات أولية، والأكواد التي تبدأ بالرقم 2 تشير إلى نجاح العملية، والأكواد التي تبدأ بالرقم 3 تتعلق بإعادة التوجيه، والأكواد التي تبدأ بالرقم 4 تدل على خطأ من جهة العميل، بينما تشير الأكواد التي تبدأ بالرقم 5 إلى خطأ من جهة الخادم، تستخدم الأكواد لتوضيح حالة الطلب، سواء كان ناجحًا أو يتطلب حل مشكلة.

الأمثلة النصية التالية تعرض صياغة HTTP/1.1، ولا تصف خدمات فعلية على عناوين الأمثلة. تفصل أسطر الرؤوس بـ CRLF وتنتهي بسطر فارغ. أطوال الأجسام محسوبة ببايتات UTF-8 مع LF بين أسطر الجسم ما لم ينص المثال على غير ذلك. بعض المقاطع تعرض الرؤوس فقط ويذكر ذلك بجانبها.

HTTP Status code components مكونات كود الحالة HTTP

أكواد الحالة status codes تتكون من ثلاثة أرقام، وتشكّل هذه الأرقام معًا كودًا واحدًا يشير إلى حالة معينة.

الرقم الأول First Number
يحدد فئة الاستجابة response category وهو مؤشر رئيسي على نوع الاستجابة response type التي يقدمها الخادم. هناك خمس فئات رئيسية يتم تمثيلها بالأرقام من 1 إلى 5، كما يلي:

  • Informational Responses 1xx الاستجابات المعلوماتية: تشير إلى أن الطلب قيد الاستلام والمعالجة.

  • Successful Responses 2xx الاستجابات الناجحة: تعني أن الطلب قد نجح وتمت معالجته بشكل صحيح.

  • Redirection Messages 3xx رسائل إعادة التوجيه: تدل على أن التحميل يحتاج إلى إجراء إضافي، مثل الانتقال لموقع آخر.

  • Client Errors Responses 4xx استجابات أخطاء العميل: تشير إلى خطأ من المستخدم، مثل طلب غير موجود.

  • Server Errors Responses 5xx استجابات أخطاء الخادم: تدل على أن الخادم فشل في تنفيذ الطلب.

الرقمان الأخيران Last Two Digits
لا يتم استخدام الرقمان الأخيران في عملية التصنيف، ولكنهما يحددان الحالة الدقيقة ضمن الفئة العامة التي يشير إليها الرقم الأول، كل كود من أكواد الحالة يتألف عادة من استجابة فريدة تشرح بشكل أكثر تحديدًا طبيعة الطلب أو المشكلة.

HTTP Codes In Informational Responses الاستجابات المعلوماتية في HTTP Codes

تتكون استجابة informational responses عادةً من سطر حالة HTTP status line، ورأس header، وتنتهي بسطر فارغ، وتدعم الإصدارات الحديثة استجابات معلوماتية أيضًا؛ أما 101 الخاص بتبديل اتصال HTTP/1.1 فليس مستخدمًا في HTTP/2 وHTTP/3. لا ترسل استجابة 1xx إلى عميل HTTP/1.0، ولذلك، يجب على الخوادم ألا ترد بكود 1xx على طلبات من عملاء يستخدمون HTTP/1.0، بما أن أكواد HTTP 1xx تُعتبر فقط لأغراض معلوماتية، فإن المتصفحات والوكلاء المستخدمَة لن تقوم بمعالجة أو عرض هذه الأكواد على الشاشة الأمامية مثل ما تفعل مع فئات الأكواد الأخرى، بل تعالج دلالتها المدعومة، مثل السماح بإرسال الجسم أو التلميحات المبكرة، وتنتظر الاستجابة النهائية. يمكن تجاهل كود معلوماتي غير معروف، ولا يعني ذلك تجاهل كل 1xx.

توضح القائمة التالية أربعة أمثلة من سلسلة 1xx، ويراجع سجل IANA للأكواد المسجلة وتحديثاتها؛ ليست القائمة حصرًا ثابتًا لكل كود وهي عبارة عن إشارات معلوماتية لتوجيه عملية الاتصال وهذا يُساعد في تحسين التفاعل بين الخادم والعميل أثناء معالجة الطلبات.

أكواد HTTP الخاصة بالاستجابات المعلوماتية Informational Responses

  • متابعة 100 Continue: يشير إلى أن الخادم تلقى الجزء الأول من الطلب وعلى العميل متابعة إرسال باقي البيانات.

  • بروتوكولات التبديل 101 Switching Protocols: يعني أن الخادم يوافق على تغيير البروتوكول بناءً على طلب العميل للاستفادة من إمكانيات مختلفة مثل التحويل من HTTP إلى Web Socket. 

  • المعالجة 102 Processing: يدل على أن الخادم يستغرق وقتًا أطول لمعالجة الطلب والذي يحتاج إلى عمليات أطول قبل الوصول إلى استجابة نهائية.

  • تلميحات مبكرة 103 Early Hints: يوفر للعملاء تلميحات مبكرة عن الموارد التي يمكن جلبها بشكل مسبق قبل أن يتم الحصول على الاستجابة النهائية للطلب.

HTTP 100 Continue متابعة HTTP 100

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

هذه الاستجابة تُعزز من فعالية الاتصال خاصة عند التعامل مع بيانات كبيرة أو معقدة، إذ تُمكن من تجنب إرسال محتوى كامل إذا كان هناك خطأ في الجزء الأول من الطلب، قد يقلل Expect: 100-continue إرسال جسم كبير إذا رفض الخادم الطلب مبكرًا، لكنه لا يضمن تسريع كل اتصال. يمكن للعميل إرسال الجسم بعد انتظار مناسب دون تلقي 100، وقد يكون الجسم قد وصل بالفعل.

The Status

نمط كود الحالة 100 Continue

نص
100 Continue

100 Request from client to server using continue

يطلب العميل تأكيد من الخادم باستخدام الكود 100 continue قبل تحميل ملف كبير بالكامل.

المقطع التالي رؤوس طلب فقط؛ جسم الملف ذي الحجم المعلن غير معروض. ينتهي قسم الرؤوس بسطر فارغ قبل انتظار 100 أو إرسال الجسم.

نص
POST /upload HTTP/1.1
Host: www.example.com
Content-Length: 10256423
Expect: 100-continue

Server response to the client

تُشير الاستجابة response إلى أن الخادم استلم جزء من الطلب ويأذن للعميل بمواصلة إرسال باقي البيانات.

نص
HTTP/1.1 100 Continue

HTTP 101 Switching Protocols بروتوكولات التبديل HTTP 101

هو أحد اكواد الحالة التي قد نُواجهها في عالم الشبكات، فعندما يُرسل العميل طلبًا إلى الخادم باستخدام بروتوكول HTTP، قد يطلب العميل عبر رأس Upgrade تبديل الاتصال إلى بروتوكول آخر، والذي قد يكون أحدث أو أكثر ملاءمة لتطبيق مُعين، مثل الانتقال من HTTP إلى WebSocket.

عندما يقوم الخادم بالموافقة على طلب العميل لتبديل البروتوكول، فإنه يُصدر كود الحالة Switching Protocols 101، يعني  أن الخادم قد وافق على التغيير، وأصبح الاتصال الآن يستخدم البروتوكول الجديد WebSocket.

The Status

نمط كود الحالة 101 Switching Protocols

نص
101 Switching Protocols

Request from Client to Server Using Switching Protocols 101

عندما يريد العميل التبديل من HTTP إلى WebSocket، يُرسل طلبًا يحتوي على تفاصيل التبديل في رأس الطلب.

نص
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Server response to the client

إذا كان الخادم يدعم WebSocket ويرغب في ترقية الاتصال، فإنه يرد بكود الحالة 101 Switching Protocols.

نص
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

HTTP 102 Processing المعالجة HTTP 102

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

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

The Status

نمط كود الحالة 102 Processing

نص
102 Processing

Client request followed by 102 Processing

يستخدم الخادم كود 102 Processing لإبلاغ العميل بأن طلب البحث المعقد قيد المعالجة مع بقاء مهلة الانتظار خاضعة لتنفيذ العميل والوسيط.

نص
POST /search HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 89

{
"query": "search term",
"filters": {
"date": "2023-01-01",
"category": "technology"
}
}

Title Example of HTTP Processing Response 102

الكود HTTP 102 Processing يشير إلى أن الخادم قد استلم الطلب ويقوم بمعالجته حاليًا ولا يمثل نجاح العملية النهائي.

نص
HTTP/1.1 102 Processing

Example of HTTP 200 OK Response with JSON Search Results

استجابة HTTP 200 OK تعرض نتائج بحث بنجاح، مضمنة تفاصيل وعناوين المقالات بصيغة JSON.

نص
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 483

   {
       "status": "success",
       "results": [
           {
               "title": "Latest Technology Trends",
               "link": "https://example.com/articles/1",
               "snippet": "Explore the latest technology trends for 2023..."
           },
           {
               "title": "AI Innovations",
               "link": "https://example.com/articles/2",
               "snippet": "Discover the innovations in AI for the new year..."
           }
       ]
   }

HTTP 103 Early Hints تلميحات مبكرة HTTP 103

يُعتبر الكود 103 Early Hints جزءًا من بروتوكول نقل النصوص HTTP، ويمثل أحد التطورات الهامة في تحسين أداء تصفح الويب، ويُستخدم هذا الكود لإرسال تلميحات مبكرة من الخادم إلى العميل [المتصفح] حول الموارد التي ينبغي تحميلها مسبقًا، وذلك قبل اكتمال معالجة الطلب الرئيسي.

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

The Status

نمط كود الحالة Early Hints 103

نص
103 Early Hints

Preconnect example

استجابة 103 Early Hint توصي بـ "rel=preconnect" لـ [https://assets.example.net] لتحسين التحميل.

نص
HTTP/1.1 103 Early Hints
Link: <https://assets.example.net>; rel=preconnect, <https://assets.example.net>; rel=preconnect; crossorigin

هذا المثال يتصل مسبقًا بـ https://assets.example.net مرتين:

  • الاتصال الأول سيكون لتحميل الموارد التي يمكن جلبها بدون CORS، مثل مقاطع الفيديو.
  • الاتصال الثاني يتضمن سمة "crossorigin" وسيكون لتحميل طلبات CORS مثل جلب الخطوط. الصورة العادية لا تتطلب CORS افتراضيًا، ويتوقف ذلك على طريقة استخدامها وخصائص الطلب. crossorigin يحدد وضع CORS وبيانات الاعتماد، وليس تشفير المورد أو ضمان إنشاء اتصال شبكة مستقل.

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

Final Response for Secure Font and Image Loading via CORS

يرسل الخادم الاستجابة النهائية التي تشمل تحميل خط بوضع CORS مع crossorigin وصورة من الأصل الإضافي.

نص
HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>

<link rel="preload" href="https://assets.example.net/fonts/custom-font.woff2" as="font" type="font/woff2" crossorigin>

<img src="https://assets.example.net/photos/sample.jpg" alt="">

Preload example

تشير استجابة 103 Early Hints إلى أنه قد يكون هناك حاجة إلى تحميل مسبق لملف جافا سكريبت "app.js".

نص
HTTP/1.1 103 Early Hints
Link: </scripts/app.js>; rel=preload; as=script

Final response with preloaded JavaScript app loaded

الخادم يرسل استجابة نهائية تتضمن تحميل تطبيق جافا سكريبت المحمّل مسبقًا من التلميحات المبكرة.

نص
HTTP/1.1 200 OK
Content-Type: text/html

<!doctype html>

<script src="/scripts/app.js"></script>

Early hint response with CSP

في هذا المثال، تظهر نفس استجابة Early Hints مع تضمين رأس سياسة أمان المحتوى [Content-Security-Policy].

نص
HTTP/1.1 103 Early Hints
Content-Security-Policy: script-src 'self';
Link: </scripts/app.js>; rel=preload; as=script
تحدّد الاستجابة المبكرة أن التحميل المسبق مسموح به فقط من النطاق الأصلي للطلب، سيتم تحميل ملف الجافا سكريبت مسبقًا إذا كان موجودًا على نفس النطاق.

قد تقوم الاستجابة النهائية بتعيين CSP إلى "none"، كما هو موضح في المثال ادناه، تم تحميل الجافا سكريبت مسبقًا، ولكنه لن يُستخدم عند عرض الصفحة.

HTTP response with content security policy restrictions

الاستجابة HTTP 200 OK تطبق سياسة أمان المحتوى CSP لحظر تنفيذ سكربتات JavaScript كوسيلة لتعزيز الأمان.

نص
HTTP/1.1 200 OK
Content-Security-Policy: script-src 'none';
Content-Type: text/html

<!doctype html>
<script src="/scripts/app.js"></script>

HTTP Codes In Successful Responses الاستجابات الناجحة في HTTP Codes

هذه الفئة من أكواد الاستجابة تُشير إلى أنّ الطلب الذي قام به المستخدم للخادم قد نُفِّذ بنجاح.، مثل [200]، وتدل علي نجاح العملية بإرجاع البيانات المطلوبة، مثل صفحة ويب أو معلومة من قاعدة بيانات.


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


أكواد HTTP الخاصة بالاستجابات الناجحة Successful Responses


  • الكود 200 OK : يشير إلى أن الطلب قد تمت معالجته بنجاح، وأن الخادم أرسل البيانات المطلوبة إلى المتصفح.

  • تم الإنشاء 201 Created : يدل على أن الطلب قد أدى إلى إنشاء مورد جديد، مثل إنشاء سجل جديد في قاعدة البيانات أو ملف.

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

  • معلومات عُدّلت لدى وسيط 203 Non-Authoritative Information: يعني أن وكيلًا حوّل محتوى استجابة المصدر الأصلية 200 قبل إرسالها؛ لا يعني رفض الصلاحيات أو إعادة التوجيه.

  • بدون محتوى 204 No Content : يُستخدم للإشارة إلى أن الخادم قام بمعالجة الطلب ولكنه لا يحتوي على أي محتوى لعرضه، حيث يمكن أن يُستخدم لتحديث البيانات دون تغيير في الواجهة الظاهرة.

  • إعادة تعيين المحتوى 205 Reset Content : يعني أنه ينبغي على العميل إعادة تعيين واجهته، مثل إعادة النموذج إلى حالته الأولية؛ لا تحمل استجابة 205 جسم محتوى.

  • المحتوى الجزئي 206 Partial Content : يدل على أن الخادم يعيد جزءًا من المحتوى، والذي يُستخدم عادة لتنزيل بعض أجزاء الملفات مثل مقاطع الفيديو أو الصوت.

  • متعدد الحالات 207 Multi-Status: يستخدم هذا الكود للرد على طلب يتضمن عمليات متعددة، حيث يتم عرض حالات نجاح وفشل مختلفة لكل مورد.

  •  تم الإبلاغ عنها بالفعل 208 Already Reported: يستخدم داخل DAV:propstat في استجابة WebDAV متعددة الحالات لتجنب تكرار موارد لها ارتباطات متعددة، وفق شروط امتداد BIND.

  • تم استخدام 226 IM Used: يشير إلى استجابة GET بعد تطبيق instance-manipulations متفاوض عليها، مثل إرسال فرق delta عن نسخة يملكها العميل؛ لا يعني الهندسة العكسية أو نجاحًا جزئيًا عامًا.

HTTP 200 Code الكود HTTP 200

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

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

The Status

نمط كود الحالة 200 OK

نص
200 OK

HTML Get Request with Client Info and Content Preferences

إرسال طلب HTTP من المتصفح إلى الخادم على الشكل التالي.

نص
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive

The HTTP 200 OK response includes a sample HTML page

سيقوم الخادم بالرد بكود 200 OK وإرسال الصفحة المطلوبة إلى المتصفح.

نص
HTTP/1.1 200 OK
Date: Mon, 23 Oct 2023 12:00:00 GMT
Server: Apache/2.4.41 (Unix)
Content-Type: text/html
Content-Length: 149

<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <h1>Welcome to Example.com!</h1>
    <p>This is an example page.</p>
</body>
</html>

HTTP 201 Created تم إنشاؤه HTTP 201

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


يتم استخدامه عادة في الرد على طلبات HTTP POST التي تؤدي إلى إنشاء مورد جديد على الخادم، ولكن يمكن أيضًا أن يكون مناسبًا لطلبات HTTP PUT إذا أدى إلى إنشاء جسم جديد.



وفيما يلي بعض المواضيع التي نستخدام  فيها كود الحالة 201:


  • عند إنشاء حساب مستخدم جديد
  • عند إضافة منتج جديد إلى متجر عبر الإنترنت
  • عند إرسال نموذج على موقع الويب يؤدي إلى إنشاء سجل جديد

The Status

نمط كود الحالة 201 Created

نص
201 Created

Create a new user using a HTTP POST request

طلب POST HTTP لإنشاء حساب جديد باسم "example_user" والبريد الإلكتروني "[email protected]" بتنسيق JSON.

نص
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 66

{
  "username": "example_user",
  "email": "[email protected]"
}

Successfully responded to create a new user

استجابة Code 201 تحتوي على بيانات المستخدم الجديد بنجاح مع تفاصيل الهوية، اسم المستخدم، البريد الإلكتروني، وتاريخ الإنشاء.

نص
HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 12345,
  "username": "example_user",
  "email": "[email protected]",
  "created_at": "2022-01-01T12:00:00Z"
}

202 Accepted القبول 202

الكود HTTP Accepted 202 يُعرف بأنه "مقبول"، حيث يُشير إلى استلام الطلب وفهمه من قِبل الخادم، ولكن قد تتأخر عملية معالجة الطلب أو لا تكتمل في الوقت الحالي. لا يضمن نجاح المعالجة لاحقًا؛ قد تفشل أو يُرفض تنفيذها عند إتمام الفحص.


باختصار، الكود الحالة 202 Accepted يُظهر أن الطلب تم قبوله، لكن قد يستغرق الأمر بعض الوقت لاكتمال معالجته أو الإجراء المطلوب.

The Status

نمط كود الحالة 202 Accepted

نص
202 Accepted

Create a new account via HTTP POST request in HTTP/1.1

استخدم POST HTTP/1.1 لإنشاء حساب جديد مع بيانات المستخدم مثل اسم المستخدم وكلمة المرور بتنسيق JSON.

نص
POST /create_account HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 63

{
  "username": "new_user",
  "password": "securepassword123"
}

HTTP 202 Accepted response displaying account creation progress via HTTP/1.1, time, and message data in JSON format.

رد HTTP بكود HTTP Accepted 202 يُظهر أن عملية إنشاء الحساب قيد التقدم وتحت المتابعة، ويتضمن رسالة تفيد بذلك بتنسيق JSON.

نص
HTTP/1.1 202 Accepted
Date: Wed, 15 Sep 2021 08:00:00 GMT
Content-Type: application/json
Content-Length: 47

{
  "message": "Account creation in progress"
}

HTTP 203 Non-Authoritative Information معلومات عُدّلت لدى وسيط 203

كود 203 Non-Authoritative Information يعني أن الطلب نجح، لكن وكيلًا حوّل محتوى استجابة 200 التي أرسلها الخادم الأصلي قبل تمريرها للعميل.

من أمثلته أن يعدل وسيط تمثيل المحتوى وفق وظيفة متفق عليها؛ لا يعني نقل المورد أو إعادة توجيه العميل إلى مصدر آخر. يُعلم العميل أن الاستجابة قد تكون مقدمة من خادم وكيل أو طرف ثالث وقد تتأثر إعادة التحقق من النسخة المخزنة بمسار الوسيط الذي عدلها. الاسم لا يعني رفض التفويض أو حكمًا بأن الموقع خبيث. يميز المثال التالي المحتوى الذي عدله الوسيط؛ ليس رأس Location هو ما يعرّف دلالة 203.

The Status

نمط كود الحالة 203 Non-Authoritative Information

نص
203 Non-Authoritative Information

Get ideal resources from www.example.com

في هذا الطلب، يتم إرسال طلب GET إلى الخادم www.example.com لاسترجاع الموارد المتواجدة في المسار /example.

نص
GET /example HTTP/1.1
Host: www.example.com

A proxy returns transformed content

يفترض المثال أن المصدر أعاد 200 بمحتوى، ثم عدل الوسيط تمثيله وأعاد 203. لا يعيد توجيه المستخدم إلى عنوان آخر.

نص
HTTP/1.1 203 Non-Authoritative Information
Date: Wed, 23 Jun 2021 12:00:00 GMT
Content-Type: text/plain; charset=utf-8
Connection: close
Content-Length: 33

Content transformed by the proxy.

204 No Content بدون محتوى 204

كود الحالة 204 HTTP No Content يُستخدم في بروتوكول HTTP للإشارة إلى أن الطلب تم تنفيذه بنجاح من قِبَل الخادم، ولكن لا توجد بيانات لتُرجع للعميل.

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

The Status

نمط كود الحالة 204 No Content

نص
204 No Content

Query for user profile in JSON format

الطلب المرسل يستفسر عن ملف تعريف المستخدم المُخزن على الخادم، حيث يطلب بتنسيق JSON لتبادل البيانات.

نص
GET /api/user/profile HTTP/1.1
Host: example.com
Accept: application/json

Response with status code HTTP No Content 204 to user profile request.

استجابة بكود الحالة HTTP 204 No Content تأكد تنفيذ الطلب بنجاح دون وجود أية بيانات لإرجاعها.

نص
HTTP/1.1 204 No Content
Date: Sun, 12 Dec 2021 08:30:00 GMT
Server: Apache/2.4.6 (CentOS)

205 Reset Content إعادة تعيين المحتوى 205

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


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

The Status

نمط كود الحاله 205 Reset Content

نص
205 Reset Content

HTTP POST message to reset the form on the example.com server

رسالة HTTP POST لإعادة تعيين النموذج على example.com تحتوي على بيانات JSON مع مفتاح reset وقيمة true.

نص
POST /reset-form HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 17

{
"reset": true
}

Reset the input view without a response body

استجابة تطلب إعادة النموذج لحالته الأولية، دون جسم رسالة

نص
HTTP/1.1 205 Reset Content
Content-Length: 0

206 Partial Content المحتوى الجزئي 206

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

The Status

نمط كود الحالة 206 Partial Content

نص
206 Partial Content

Request to download video file with byte range specified

طلب HTTP GET لملف الفيديو video.mp4 من example.com بنطاق البايتات 0-999 واتصال مستمر.

نص
GET /video.mp4 HTTP/1.1
Host: example.com
Range: bytes=0-999
Connection: keep-alive

HTTP response with code 206 Partial Content sends a portion of the video file with specified scopes and size

استجابة كود HTTP Partial Content 206 تحتوي على جزء من ملف الفيديو بنطاق البايتات 0-999 من إجمالي 50000 بايت.

المقطع يعرض رؤوس الاستجابة فقط؛ جسم الفيديو المؤلف من 1000 بايت غير مرفق. ليس النص التالي ملف MP4 يمكن تشغيله.

نص
HTTP/1.1 206 Partial Content
Date: Wed, 26 May 2021 07:30:15 GMT
Content-Type: video/mp4
Content-Length: 1000
Content-Range: bytes 0-999/50000

207 Multi Status متعدد الحالات 207

هذا الكود يستخدم في بروتوكول نقل النص الفائق HTTP، ويستخدم في WebDAV لتجميع حالات موارد أو خصائص متعددة في استجابة XML ذات جذر DAV:multistatus. يجب قراءة الحالات داخل الجسم؛ قد تتضمن نجاحًا جزئيًا أو فشلًا، فلا يكفي رقم 207 للحكم على كل عملية.

ترتبط كل حالة بمورد يحدده DAV:href، وفي PROPFIND توضح DAV:propstat حالات الخصائص المطلوبة. ليس 207 كودًا عامًا لدمج JSON من عدة خوادم. المثال التالي يستعلم عن خاصية اسم العرض في مجموعة WebDAV وملف داخلها.

The Status

نمط كود الحالة 207 Multi Status

نص
207 Multi Status

Request display names with WebDAV PROPFIND

طلب PROPFIND بخيار Depth: 1 يستعلم عن أسماء العرض للمجموعة /example/ وأعضائها المباشرين.

نص
PROPFIND /example/ HTTP/1.1
Host: www.example.com
Depth: 1
Content-Type: application/xml; charset=utf-8
Content-Length: 77

<D:propfind xmlns:D="DAV:">
  <D:prop><D:displayname/></D:prop>
</D:propfind>

A WebDAV XML response contains resource property statuses

استجابة 207 تحتوي حالة خاصية displayname لكل مورد. كلا الموردين ناجح هنا؛ يجب فحص DAV:status داخل كل DAV:propstat.

نص
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset=utf-8
Content-Length: 418

<D:multistatus xmlns:D="DAV:">
  <D:response><D:href>/example/</D:href><D:propstat>
    <D:prop><D:displayname>Example</D:displayname></D:prop>
    <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat></D:response>
  <D:response><D:href>/example/file.txt</D:href><D:propstat>
    <D:prop><D:displayname>File</D:displayname></D:prop>
    <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat></D:response>
</D:multistatus>

208 Already Reported تم الإبلاغ عنها بالفعل 208

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

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

هذا يُظهر الاستجابة السليمة للطلبات على الويب ويُعزز تنظيم المحتوى المُستجاب له بشكل فعال ومُنظم.

يظهر 208 داخل DAV:propstat في استجابة 207، وليس استجابة GET مستقلة. يرتبط ذلك باستعلام Depth: infinity ودعم العميل لامتداد BIND الذي يعلن عنه بـ DAV: bind، لتجنب إعادة تعداد مجموعة مرتبطة بأكثر من مسار.

The Status

نمط كود الحالة 208 Already Reported

نص
208 Already Reported

Request a WebDAV collection with binding awareness

الطلب يستعلم عن المجموعة /example/ بعمق غير محدود؛ ويعلن دعم BIND. يفترض المثال أن /example/again/ ارتباط بالمجموعة نفسها.

نص
PROPFIND /example/ HTTP/1.1
Host: www.example.com
Depth: infinity
DAV: bind
Content-Type: application/xml; charset=utf-8
Content-Length: 93

<D:propfind xmlns:D="DAV:">
  <D:prop><D:displayname/><D:resource-id/></D:prop>
</D:propfind>

A 207 response reports a repeated collection with an inner 208 status

استجابة 207 تعرض المجموعة بحالة 200 أولًا، ثم تعرض ارتباطها المتكرر بحالة 208 داخل DAV:propstat مع resource-id نفسه، وتتجنب إعادة تعداد أعضائها.

نص
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset=utf-8
Content-Length: 655

<D:multistatus xmlns:D="DAV:">
  <D:response><D:href>/example/</D:href><D:propstat>
    <D:prop><D:displayname>Example collection</D:displayname>
      <D:resource-id><D:href>urn:uuid:11111111-2222-4333-8444-555555555555</D:href></D:resource-id>
    </D:prop><D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat></D:response>
  <D:response><D:href>/example/again/</D:href><D:propstat>
    <D:prop><D:displayname>Example collection</D:displayname>
      <D:resource-id><D:href>urn:uuid:11111111-2222-4333-8444-555555555555</D:href></D:resource-id>
    </D:prop><D:status>HTTP/1.1 208 Already Reported</D:status>
  </D:propstat></D:response>
</D:multistatus>

226 IM Used تم استخدام 226

كود الاستجابة 226 IM Used يشير  أن الخادم لبّى طلب GET وأرسل تمثيلًا بعد تطبيق instance-manipulations تفاوض عليها العميل عبر A-IM، مثل فرق delta عن نسخة سابقة. قد يحتاج العميل إلى جمع الفرق مع النسخة السابقة للحصول على المحتوى الحالي. يتضمن الرد IM لتسمية التحويل وETag للنسخة الحالية، ويمكن أن يحدد Delta-Base النسخة الأساس.

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

The Status

نمط كود الحالة 226 IM Used.

نص
226 IM Used

GET request to /example on www.example.com with keep-alive connection

طلب GET باستخدام HTTP/1.1 للوصول إلى /example على www.example.com مع اتصال keep-alive لتقليل التأخير.

في هذا المثال التعليمي يملك العميل نسخة ETag="v1" ونصها old متبوعًا بـ LF، ويدعم diffe. النسخة v2 هي new متبوعة بـ LF. لا يفترض أن المتصفح العادي يطبق هذا الامتداد تلقائيًا.

نص
GET /example HTTP/1.1
Host: www.example.com
A-IM: diffe
If-None-Match: "v1"

The request was successfully used and the current version was successfully modified HTTP 226 response

استجابة HTTP 226 IM Used توضح تلبية الطلب للمورد مع تطبيق عمليات التلاعب على النسخة الحالية.

الجسم التالي خرج diff -e: يستبدل السطر الأول بالنص new. طوله 9 بايتات، بما فيها LF النهائي؛ النتيجة المعاد تكوينها new ثم LF، وليست أوامر الفرق نفسها.

نص
HTTP/1.1 226 IM Used
Content-Type: text/plain; charset=utf-8
ETag: "v2"
Delta-Base: "v1"
IM: diffe
Content-Length: 9

1c
new
.

HTTP Codes In Redirection Messages رسائل إعادة التوجيه في HTTP Codes

تُعتبر رسائل إعادة التوجيه 3xx redirection messages جزءًا مهمًا من بروتوكول نقل النصوص HTTP، حيث تُستخدم لإرشاد [المتصفح] المتصفح بأن الصفحة أو المورد المطلوب قد تم نقله إلى عنوان جديد، وتتميز هذه الرسائل بكونها تُطلب من الخادم الذي يقوم بتوجيه العميل [المتصفح] إلى مكان جديد للحصول على المعلومات المطلوبة.

يستخدم المطورون ومديرو المواقع رسائل إعادة التوجيه redirection messages لتحسين تجربة المستخدم، حيث يتم توجيه الزائرين إلى الصفحات الجديدة تلقائيًا. وتشمل رسائل إعادة التوجيه 3xx redirection messages أنواعًا مثل 301 moved permanently و 302 found، وتساعد هذه الرسائل في تحسين ترتيب المواقع في محركات البحث عبر الحفاظ على ترابط الروابط القديمة وتجنب المحتوى المكرر، مما يُحسّن وسائل SEO.

أكواد HTTP الخاصة برسائل إعادة التوجيه Redirection Messages

  • خيارات متعددة 300 Multiple Choices: يُظهر قائمة بالروابط المتاحة حيث يُمكن للمستخدم اختيار رابط للانتقال إلى الموقع المطلوب، ولا يحدد HTTP حدًا عامًا من خمسة عناوين.

  • نقل دائم 301 Moved Permanently: تم نقل الصفحة المطلوبة إلى عنوان جديد بشكل دائم ويجب تحديث جميع الروابط المتعلقة بها.

  • تم العثور 302 Found: تم نقل الصفحة المطلوبة إلى عنوان جديد بشكل مؤقت.

  • انظر لموقع آخر 303 See Other: يمكن العثور على الصفحة المطلوبة في عنوان مختلف.

  • لم يتم التعديل 304 Not Modified: هذا الكود هو استجابة للرأس [If-Modified-Since] أو [If-None-Match] في طلب GET أو HEAD شرطي، وتفيد بأن التمثيل المخزن يمكن إعادة استخدامه وفق قواعد التحقق؛ لا يعني ذلك أن نص الرابط هو الذي لم يتغير.

  • استخدام بروكسي 305 Use Proxy: كود متقادم لا يستخدم لتنفيذ توجيه جديد إلى بروكسي.

  • غير مستخدم 306 Unused: كان هذا الكود مستخدمًا في إصدار سابق ولكنه لم يعد مستخدمًا، ومع ذلك فإن الكود محجوز.

  • إعادة توجيه مؤقتة 307 Temporary Redirect: تم نقل الصفحة المطلوبة مؤقتًا إلى عنوان جديد.

يحافظ 307 و308 على طريقة الطلب وجسمه عند اتباع إعادة التوجيه، بينما قد تحول بعض حالات 301 و302 طلب POST إلى GET. يشير 303 إلى جلب المورد الآخر باستخدام GET أو HEAD. لا تمثل كل استجابة 3xx نقل صفحة؛ 304 مثلًا خاص بالتحقق من التخزين المؤقت.

HTTP 300 Multiple Choices خيارات متعددة 300 HTTP

HTML

HTTP 301 Moved Permanently نقل دائم 301 HTTP

HTML

HTTP 302 Found تم العثور 302 HTTP

HTML

HTTP 303 See Other انظر لموقع آخر 303 HTTP

HTML

HTTP 304 Not Modified لم يتم التعديل 304 HTTP

HTML

HTTP 305 Use Proxy استخدام بروكسي 305 HTTP

HTML

HTTP 306 Unused غير مستخدم 306 HTTP

HTML

HTTP 307 Temporary Redirect إعادة توجيه مؤقتة 307 HTTP

HTML

HTTP Codes In Client Errors Responses استجابات أخطاء العميل في HTTP Codes

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

يمكن لـ مطوري الويب استخدام أكواد الخطأ لتوجيههم إلى أماكن العيب، مما يسهل عليهم إصلاحها وتحسين الأداء بشكل عام. قد تظهر للمستخدم رسائل خطأ مثل 404 Not Found عندما يطلبون موارد غير متوفرة. بفهم تلك الرسائل، يمكن للمطورين تحديد سبب المشكلة ومعالجتها بفعالية.

  • أكواد HTTP الخاصة بأخطاء العميل Client Errors Responses

    • طلب سيء 400 Bad Request: يشير إلى أن الخادم لم يتمكن من فهم الطلب بسبب تنسيق غير صحيح.

    • غير مصرح به 401 Unauthorized: يعني غياب بيانات مصادقة صالحة للمورد، ويجب أن يتضمن الرد تحديًا مناسبًا في WWW-Authenticate. رفض مستخدم معروف يختلف عن الحاجة للمصادقة.

    • محظور 403 Forbidden: يشير إلى أن الخادم يرفض الوصول إلى المورد لأسباب معينة.

    •  غير موجود 404 Not Found: يدل على عدم توفر المورد المطلوب على الخادم.

    •  انتهاء الوقت المسموح للطلب 408 Request Timeout: يحدث عندما يتجاوز الطلب الحد الزمني المسموح به.

    • 419: رقم غير مسجل ككود HTTP قياسي لدى IANA؛ قد تستخدمه بعض التطبيقات لانتهاء جلسة أو رمز CSRF، وتحدد وثائق التطبيق معناه.

    • طلبات زائدة 429 Too Many Requests: يعني أن العميل قام بإرسال الكثير من الطلبات في وقت قصير.

    • غير متاح لأسباب قانونية 451 Unavailable For Legal Reasons: يستخدم عندما يكون الموارد غير متوفرة بسبب أسباب قانونية.

HTTP Codes In Server Errors Responses استجابات أخطاء الخادم في HTTP Codes

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

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

أكواد HTTP الخاصة باستجابات أخطاء الخادم Server Error Responses:

  • خطأ داخلي في الخادم 500 Internal Server Error: يظهر عند مواجهة الخادم لخطأ غير متوقع يمنعه من تنفيذ الطلب.

  • غير مُنفّذ 501 Not Implemented: يشير إلى أن الخادم لا يدعم الوظيفة المطلوبة لتنفيذ الطلب.

  • خطأ في بوابة الاتصال 502 Bad Gateway: يعني أن الخادم استلم استجابة غير صالحة من الخادم الآخر أثناء محاولة معالجة الطلب.

  • الخدمة غير متوفرة 503 Service Unavailable: يدل على أن الخادم غير قادر على معالجة الطلب في الوقت الحالي بسبب الحمل الزائد أو الصيانة المؤقتة.

  • مهلة بوابة الاتصال 504 Gateway Timeout: يشير إلى أن الخادم لم يستلم استجابة في الوقت المناسب من الخادم الآخر أثناء محاولته لمعالجة الطلب.

  • إصدار HTTP غير مدعوم 505 HTTP Version Not Supported: يعني أن الخادم لا يدعم إصدار HTTP المستخدم في الطلب.

مشاركة

هل كان هذا الدرس مفيدًا؟

جارٍ تحميل الآراء…