في هذا الدرس 29تصفّح المواضيع
HTTP Status Codes
أكواد حالة HTTP
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
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
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
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 101 Switching Protocols بروتوكولات التبديل HTTP 101
عندما يقوم الخادم بالموافقة على طلب العميل لتبديل البروتوكول، فإنه يُصدر كود الحالة 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
HTTP 102 Processing المعالجة HTTP 102
هذا الكود يكون مفيدًا بشكل خاص في الحالات التي يحتاج فيها الخادم إلى وقت طويل لاستكمال المعالجة، مما يساعد في الحفاظ على التواصل بين العميل والخادم وإبلاغه باستمرار المعالجة؛ لا يضمن أن كل عميل أو وسيط سيطيل مهلته.
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
HTTP 103 Early Hints تلميحات مبكرة HTTP 103
يهدف الكود 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
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 200 Code الكود HTTP 200
يُستخدم هذا الكود في عمليات تبادل البيانات بين العميل والخادم، سواء كان ذلك في تحميل صفحة ويب، أو الوصول إلى ملفات، أو إرسال بيانات معينة.
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
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
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
HTTP 203 Non-Authoritative Information معلومات عُدّلت لدى وسيط 203
من أمثلته أن يعدل وسيط تمثيل المحتوى وفق وظيفة متفق عليها؛ لا يعني نقل المورد أو إعادة توجيه العميل إلى مصدر آخر. يُعلم العميل أن الاستجابة قد تكون مقدمة من خادم وكيل أو طرف ثالث وقد تتأثر إعادة التحقق من النسخة المخزنة بمسار الوسيط الذي عدلها. الاسم لا يعني رفض التفويض أو حكمًا بأن الموقع خبيث. يميز المثال التالي المحتوى الذي عدله الوسيط؛ ليس رأس 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 No Content بدون محتوى 204
يُستخدم هذا الكود لتأكيد استلام الطلب وتنفيذه دون الحاجة لإعادة عرض المحتوى. قد تستخدم هذه الحالة في حالات يكون فيها الهدف هو تأكيد تنفيذ الطلب دون الحاجة إلى بيانات إضافية.
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
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
206 Partial Content المحتوى الجزئي 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
207 Multi Status متعدد الحالات 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
208 Already Reported تم الإبلاغ عنها بالفعل 208
يُستخدم كود الحالة 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 تم استخدام 226
بمعنى آخر، عندما يظهر كود الاستجابة 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
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
HTTP 300 Multiple Choices خيارات متعددة 300 HTTP
HTTP 301 Moved Permanently
نقل دائم 301 HTTP
HTTP 301 Moved Permanently نقل دائم 301 HTTP
HTTP 302 Found
تم العثور 302 HTTP
HTTP 302 Found تم العثور 302 HTTP
HTTP 303 See Other
انظر لموقع آخر 303 HTTP
HTTP 303 See Other انظر لموقع آخر 303 HTTP
HTTP 304 Not Modified
لم يتم التعديل 304 HTTP
HTTP 304 Not Modified لم يتم التعديل 304 HTTP
HTTP 305 Use Proxy
استخدام بروكسي 305 HTTP
HTTP 305 Use Proxy استخدام بروكسي 305 HTTP
HTTP 306 Unused
غير مستخدم 306 HTTP
HTTP 306 Unused غير مستخدم 306 HTTP
HTTP 307 Temporary Redirect
إعادة توجيه مؤقتة 307 HTTP
HTTP 307 Temporary Redirect إعادة توجيه مؤقتة 307 HTTP
HTTP Codes In Client Errors Responses
استجابات أخطاء العميل في HTTP Codes
HTTP Codes In Client Errors Responses استجابات أخطاء العميل في HTTP Codes
يمكن لـ مطوري الويب استخدام أكواد الخطأ لتوجيههم إلى أماكن العيب، مما يسهل عليهم إصلاحها وتحسين الأداء بشكل عام. قد تظهر للمستخدم رسائل خطأ مثل 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: يستخدم عندما يكون الموارد غير متوفرة بسبب أسباب قانونية.
- طلب سيء 400 Bad Request: يشير إلى أن الخادم لم يتمكن من فهم الطلب بسبب تنسيق غير صحيح.
HTTP Codes In Server Errors Responses
استجابات أخطاء الخادم في HTTP Codes
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 المستخدم في الطلب.
سجّل الدخول لحفظ تقدمك
تابع إنجاز المواضيع والمصطلحات والمهام، وكمّل من آخر خطوة على أي جهاز.