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

حقول الرأس HTTPHTTP Header Fields

حقول الرأس HTTP
ابدأ التعلّم
أقسام الدرس
31
الأمثلة
71
اللغة
العربية
تاريخ النشر
المشاهدات
1,610
محتوى الدرس
في هذا الدرس 31تصفّح المواضيع

HTTP Header Fields حقول الرأس HTTP

تُعتبر حقول الرؤوس header fields في بروتوكول HTTP جزءًا مهمًا يُضيف معلومات إضافية للاتصال بين العميل والخادم، مما يساعد في تنظيم ومعالجة البيانات على الإنترنت، وتتكون رؤوس الطلبات أو الاستجابات بطريقة معينة، حيث يتكون كل رأس من اسم، ويُكتب كل رأس في سطر منفصل متبوعًا بنقطتين ومسافة اختيارية في صياغة HTTP/1.1، على النحو التالي: المفتاح: القيمة "key: value".

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

الأمثلة النصية تخص HTTP/1.1، حيث تفصل أسطر الرؤوس بـ CRLF وينتهي قسمها بسطر فارغ. HTTP/2 وHTTP/3 لهما ترميز مختلف. المقاطع التي تعرض عدة قيم مستقلة للرأس أمثلة بديلة وليست رسالة واحدة تجمعها. العناوين تعليمية وليست نقاط خدمة فعلية.

Importance and Uses of HTTP Header Fields أهمية واستخدامات حقول رأس HTTP

تلعب حقول الرؤوس headers fields في بروتوكول HTTP دورًا حيويًا في تحسين الكفاءة، والأمان، وسهولة التفاعل بين العميل والخادم، بعض الأهميات والاستخدامات البارزة لحقول الرؤوس headers fields:

  • التحكم في نوع المحتوى: يحدد الحقل مثل "Content-Type" نوع البيانات التي يتم نقلها، مما يساعد العميل في فهم كيفية معالجة أو عرض المحتوى، على سبيل المثال، يمكن تحديد ما إذا كان المحتوى عبارة عن نص عادي، أو صورة، أو ملف JSON.

  • إدارة الجلسات والتحقق من الهوية: تُستخدم حقول مثل "Authorization" و"Set-Cookie" للتحقق من هوية المستخدمين وتحديد صلاحيات الوصول، يساهم ذلك في حماية الموارد الحساسة ومنع الوصول غير المصرح به.

  • التخزين المؤقت: تسهل الحقول مثل "Cache-Control" و"Expires" عمليات التخزين المؤقت للبيانات، مما يحسِّن من سرعة استجابة المواقع عن طريق تقليل الطلبات المتكررة للخادم لنفس البيانات.

  • إدارة الاتصالات: يساعد حقل مثل "Connection" في إدارة كيفية إبقاء الاتصالات مفتوحة، مما يمكن أن يقلل من وقت تحميل الصفحات عن طريق إعادة استخدام الاتصالات القائمة بالفعل.

  • الأمان والخصوصية: تُستخدم حقول مثل "Strict-Transport-Security" و"Content-Security-Policy" لتعزيز أمان الاتصال عن طريق فرض نقل البيانات عبر قنوات مشفرة وحماية الموقع من هجمات الويب الشائعة.

  • تخصيص الاستجابة: يمكن للحقول مثل "Accept-Language" و"Accept-Encoding" أن تساعد الخادم في تخصيص المحتوى بناءً على تفضيلات المستخدم، مثل اللغة المفضلة أو نوع الضغط المستخدم.

  • مراقبة وتحليل الأداء: تمتلك بعض الحقول وظائف تمكن مسؤولي الشبكة والمطورين من تتبع أداء الموقع، مثل "Server-Timing" الذي يوفر نظرة على زمن الاستجابة والأداء العام للطلبات.

Connection يخص HTTP/1.x ولا يرسل في HTTP/2 أو HTTP/3. يتعلم المتصفح HSTS من استجابة HTTPS صحيحة، ولا يحمي الزيارة الأولى عبر HTTP إلا إذا كانت سياسة مناسبة معروفة مسبقًا؛ أما CSP فتضبط مصادر المحتوى ولا تنشئ تشفير TLS بذاتها.

Types of HTTP Header Fields أنواع حقول رأس HTTP

أنواع حقول رأس HTTP Header Fields

  • رؤوس الطلب Request Headers: تحتوي رؤوس الطلب على مزيد من المعلومات حول المورد الذي يجب جلبه، أو حول العميل الذي يقوم بطلب المورد.

  • رؤوس الاستجابة Response Headers: تحتوي رؤوس الاستجابة على معلومات إضافية حول الاستجابة، مثل موقعها أو معلومات حول الخادم الذي يوفرها.

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

  • رؤوس الحمولة Payload headers: تحتوي رؤوس الحمولة على معلومات مستقلة عن التمثيل حول بيانات الحمولة، بما في ذلك طول المحتوى والترميز المستخدم من أجل النقل. 

HTTP Request Headers رؤوس الطلب HTTP

تُعد طلبات HTTP Request Headers جزءًا حيويًّا في تقنيات الويب حيث تُنقل المعلومات بين العميل والخادم لتحسين تجربة التصفح، عند زيارة موقع ويب، يرسل المتصفح طلب HTTP إلى الخادم الذي يستضيف الموقع، وتُرفق مع الطلب بيانات إضافية تُسمى الرؤوس Headers مثل نوع المحتوى المطلوب واللغات المفضلة.

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

أنواع رؤوس طلبات Requests Headers HTTP

  • Authorization: يحتوي على بيانات اعتماد المستخدم للتحقق من الهوية من وكيل المستخدم مع الخادم.
  • If-Match: يجعل الطلب مشروطًا ويطبق الطريقة فقط إذا كان المورد المخزن يتوافق مع أحد التعرّفات المدعومة.
  • If-None-Match: يقوم بجعل الطلب مشروطًا ويطبق الطريقة فقط إذا لم يتوافق المورد المخزن مع أي من التعرّفات المدعومة.
  • If-Modified-Since: يقوم بجعل الطلب مشروطًا ويتوقع فقط أن يتم نقل المورد إذا تم تعديله بعد التاريخ المحدد.
  • If-Unmodified-Since: يقوم بجعل الطلب مشروطًا ويتوقع فقط أن يتم نقل المورد إذا لم يتم تعديله بعد التاريخ المحدد.
  • User-Agent: يحتوي على سلسلة تُمَكِّن قرناء البروتوكول الشبكي من تحديد نوع التطبيق، نظام التشغيل، مورد البرمجيات أو إصدار البرمجيات لوكيل المستخدم المطلوب.
  • Referer: يُظهر عنوان صفحة الويب السابقة من أين تم اتباع رابط للصفحة المطلوبة الحالية.

HTTP Authorization التفويض HTTP

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

  • يتكون رأس التفويض Authorization من <auth-scheme> الذي يُحدد نوع التفويض مثل [Basic أو Bearer] بينما يُعبِّر "<authorization-parameters>" عن بيانات الاعتماد مثل [الرمز أو معلومات تسجيل الدخول المرمّزة وفق مخطط المصادقة].

اسم الرأس Authorization لا يعني منح صلاحية تلقائيًا؛ يحمل بيانات المصادقة، ثم يطبق الخادم سياسة التفويض. Basic يستخدم Base64 القابل للعكس، لذلك يحتاج نقلًا محميًا مثل HTTPS.

Authorization header pattern

نمط رأس التفويض Authorization

نص 
Authorization: <auth-scheme> <authorization-parameters>

Example of Authorization header

في Basic Authorization، يرمّز العميل بيانات الدخول بصيغة Base64 دون تشفيرها في رأس التفويض للتحقق ومنح الوصول.

نص 
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

HTTP If-Match إذا تطابق HTTP

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

يفيد HTTP If-Match مطوري تطبيقات الويب في تجنب فقدان التحديثات المتزامنة. عند تحديث البيانات، فمن خلال فهم HTTP If-Match وتحليل رموز الحالة يمكن تحسين أداء التطبيقات وضمان موثوقية التحديثات. 

يقارن If-Match علامات ETag بمقارنة قوية؛ عدم تحقق الشرط يؤدي عادةً إلى 412 Precondition Failed، مع الحالات الاستثنائية الموثقة في RFC 9110. القيمة * تشترط وجود تمثيل حالي، وليست ETag حرفية. أمثلة الرؤوس التالية بدائل مستقلة.

If-Match header pattern

استخدام رأس HTTP If-Match للتحقق من تطابق الـ ETag لضمان عدم تعديل المورد.

نص 
If-Match: <etag_value>
If-Match: <etag_value>, <etag_value>, …

Ensuring Files Are Updated Using an ETag in HTTP

يُظهر استخدام رأس HTTP If-Match للتحقق من تطابق الـ ETag لضمان تحديث المورد بشكل مشروط.

نص 
If-Match: "d41d8cd98f00b204e9800998ecf8427e"
If-Match: "a1b2c3", "d4e5f6", "123abc"
If-Match: *

HTTP If-None-Match إذا لم يتطابق HTTP

يُعتبر HTTP If-None-Match ميزة في بروتوكول HTTP تهدف إلى زيادة كفاءة تحميل الموارد من خلال تقليل كمية البيانات المنقولة بين الخادم والمتصفح. يعتمد هذا المطلب على مفهوم "إعلام التغيير" أو "Etag"، الذي يُعرف بأنه رمز فريد يُخصص لكل نسخة من المورد المخزن على الخادم.

عندما يطلب المتصفح موردًا، يتولى الخادم التحقق من تطابق Etag المُرسل من المتصفح مع النسخة الموجودة لديه. إذا ظل المورد دون تغيير وتطابق Etag، في GET وHEAD يُرسل الخادم استجابة بحالة "304 Not Modified"، مما يعني عدم الحاجة إلى تنزيل البيانات مرة أخرى. أما إذا كان هناك تغيير ولم يتطابق Etag، يُرسل الخادم النسخة الجديدة من المورد مع Etag

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


توجد حالتا استخدام شائعتان تُعتبران أساسيتين لهذه الميزة.

الحالة الأولى تتعلق بطرق GET و HEAD، حيث تُستخدم لتحديث كيان مخزن مؤقتًا مرتبط بعلامة ETag. تُساهم هذه العملية في تحسين كفاءة استرجاع البيانات من الذاكرة المؤقتة بدلاً من طلبها مجددًا من الخادم.
الحالة الثانية تتعلق بطرق أخرى، وخاصةً طريقة PUT. يُمكن استخدام الشرط If-None-Match مع القيمة [*] لتنفيذ عملية رفع ملف عندما لا يُعرف مسبقًا إن كان الملف موجودًا بالفعل أم لا.

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

  • رأس If-None-Match يُستخدم في بروتوكول HTTP لمطابقة ETag مع النسخ المخزنة من الموارد لتحسين كفاءة نقل البيانات. عند استخدام "<If-None-Match: <etag_value"، يُتحقق من تطابق القيمة مع النسخة الموجودة، وعند فشل الشرط تُرسل 304 لطلبي GET وHEAD، أو 412 للطرق الأخرى. يستخدم If-None-Match مقارنة ضعيفة لعلامات ETag. يتضمن ""If-None-Match: W/"45de32", "23fg45", "6789op" قائمة من ETag، بما فيها القيم الضعيفة مثل [W/"45de32"]، للمقارنة مع أي نسخة مطابقة محتملة. أما " * :If-None-Match"، فيشير إلى أي إصدار موجود من المورد، ويُمكن استخدامه لضمان عدم الكتابة فوق الملفات الموجودة عند رفعها.

If-None-Match Header Patterns

أنماط رأس If-None-Match

نص 
If-None-Match: "<etag_value>"
If-None-Match: "<etag_value>", "<etag_value>", …
If-None-Match: *

Examples of using the If-None-Match header in HTTP requests

مثال لرأس If-None-Match يستخدم ETag فردي أو قائمة متعددة أو "*" لتجنب النقل غير الضروري أو استبدال الموارد.

نص 
If-None-Match: "a1b09c36279d4390df6a4d3840175e24bc61f91a"
If-None-Match: W/"45de32", "23fg45", "6789op"
If-None-Match: *

HTTP If-Unmodified-Since إذا لم يُعدّل منذ HTTP

رأس طلب HTTP If-Unmodified-Since هو أداة حيوية تساعد في تحسين أداء التطبيقات عبر الإنترنت عن طريق جعل طلبات العميل مشروطة بالتحقق من عدم تغيير المورد منذ تاريخ معين. يُستخدم هذا الرأس من قِبل العميل [مثل المتصفح] لضمان تنفيذ الطلب فقط إذا لم يتغير المورد، مما يقلل من نقل البيانات غير الضرورية بين العميل والخادم، ويعزز من كفاءة العملية واستجابتها.

عندما يقوم العميل بإرسال تاريخ آخر تعديل للنسخة المحفوظة محليًا إلى الخادم، يقوم الخادم بمقارنة هذا التاريخ مع تاريخ آخر تعديل للمورد. إذا لم يتغير المورد يسمح الشرط بمتابعة العملية المعتادة؛ لا يفرض إرسال بيانات مخزنة مؤقتًا. إذا كان أحدث من التاريخ المرسل يفشل الشرط عادةً بـ 412. يُتجاهل If-Unmodified-Since عند وجود If-Match.

يُعتبر هذا الرأس مفيدًا عند استخدام طرق غير آمنة مثل POST، حيث يساعد في تطبيق التحكم المتفائل في التزامن كما هو الحال في بعض مواقع الوِكيات، حيث تُرفض المراجعات في حال تغيير الوثيقة لضمان تجنب النزاعات. أيضًا، يُستخدم في طلبات النطاق لضمان أن الأجزاء المطلوبة تأتي من مستند غير معدل.

  • في هذا التنسيق أدناه، يمكنك استبدال "<day-name>", "<day>", "<month>", "<year>", "<hour>", "<minute>", و"<second>" بالقيم المناسبة التي تمثل التاريخ والوقت المحددين. على سبيل المثال، "<day-name>" هو "Sun"، و "<day>" هو "06"، و "<month>" هو "Nov"، و "<year>" هو "1994"، و "<hour>" هو "08"، و "<minute>" هو "49"، و "<second>" هو "37". يعبر [GMT] عن الوقت بتوقيت جرينتش.

HTTP If-Unmodified-Since header pattern

بهذا النمط يكون رأس If-Unmodified-Since

نص 
If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

Example of If-Unmodified-Since header

المثال يوضح شرطًا يعتمد على التاريخ والوقت لمزامنة الطلب مع محتوى المورد المخزن على الخادم.

نص 
If-Unmodified-Since: Sun, 06 Nov 1994 08:49:37 GMT

HTTP User-Agent وكيل المستخدم HTTP

وكيل المستخدم HTTP User-Agent، هو أحد المكونات الأساسية في عمليات تبادل البيانات عبر الإنترنت. عندما تقوم بالاتصال بأي موقع ويب، يقوم متصفحك بإرسال معلومات حول نفسه إلى الخادم الذي يستضيف هذا الموقع. هذه المعلومات تُعرف بـ[User-Agent]، وهي عبارة عن سلسلة نصية تحتوي على تفاصيل مثل نوع المتصفح، ونظام التشغيل، والأجهزة المستخدمة.

يُعتبر [User-Agent] مفيدًا بشكل كبير لأصحاب المواقع ومطوري الويب حيث يمكنهم استخدامه لفهم أنواع الأجهزة والمتصفحات التي يستخدمها زوارهم، وبالتالي تهيئة المحتوى ليتناسب بشكل أفضل مع هؤلاء المستخدمين. فمثلًا، إذا اتضح أن عددًا كبيرًا من الزوار يستخدمون أجهزة محمولة، فقد يقوم المطورون بتصميم نُسخة محسّنة للموقع لتتناسب مع الشاشات الصغيرة.

بالإضافة إلى ذلك، يساعد [User-Agent] في تحسين الأمان وقياس أداء الموقع. فقد يتم تحديد أنواع معينة من المتصفحات أو الأجهزة لاتخاذ إجراءات أمان إضافية، أو حتى تصحيح أخطاء محددة قد تؤثر على الأداء بشكل عام.

  • يتكون User-Agent من [اسم التطبيق أو المتصفح] متبوعًا بـ [النسخة]، بالأضافة الي [معلومات إضافية عن النظام أو الجهاز] عن تفاصيل مثل نوع النظام أو نسخة نظام التشغيل المستخدمة.

يمكن حذف User-Agent أو تغييره أو تقليل تفاصيله لأسباب الخصوصية؛ ليس إثبات هوية أو أساسًا موثوقًا لقرار أمني. يفضل اكتشاف الميزة المطلوبة واستخدام التصميم المتجاوب بدل افتراض القدرات من اسم المتصفح.

HTTP User-Agent header pattern

رأس"User-Agent" في HTTP يحدد اسم وإصدار المتصفح أو التطبيق ومعلومات النظام لتخصيص تجربة المستخدم.

نص 
User-Agent: [application or browser name]/[version] ([additional information about the system or device])

Example of User-Agent header

مثال علي رأس User-Agent في HTTP.

نص 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3

HTTP Referer الإحالة HTTP

HTML

HTTP response headers رؤوس الاستجابة HTTP

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

تتكون رؤوس الاستجابة من عدة أنواع، مثل رأس تاريخ الإنشاء [Date] الذي يوضح تاريخ إنشاء الرسالة، ورأس اتصال [Connection] الذي يعطي تفاصيل حول اتصال الخادم، وغيرها الكثير من الرؤوس التي تحدد خصائص وسلوكيات الاستجابة.

أنواع رؤوس استجابات Response Headers HTTP

  • WWW-Authenticate: يحدد طريقة المصادقة التي يجب استخدامها للوصول إلى المورد.
  • Proxy-Authenticate: يحدد طريقة المصادقة للوصول إلى مورد خلف خادم وكيل.
  • Age: يعطي تقدير عمر الاستجابة بالثواني منذ توليدها أو آخر تحقق ناجح منها، شاملاً زمن المرور والإقامة في مخازن متعددة.
  • Cache-Control: توجيهات لآليات التخزين المؤقت في الطلبات والاستجابات.
  • Expires: تاريخ/وقت بعده تعتبر الاستجابة قديمة.
  • Location: يحدد عنوان URL لإعادة التوجيه.
  • Connection: الذي يعطي تفاصيل حول اتصال الخادم
  • Server: يحتوي على معلومات حول البرنامج المستخدم من قِبل الخادم الأصل.
  • Timing-Allow-Origin: يحدد الأصول المسموح لها برؤية قيم السمات المستردة عبر ميزات توقيت الموارد.
  • Content-Security-Policy (CSP): يتحكم في الموارد التي يصرح للمستخدم بتحميلها لصفحة معينة.
  • Strict-Transport-Security (HSTS): يفرض الاتصالات باستخدام HTTPS بدلاً من HTTP.
  • Set-Cookie: إرسال الكوكيز من الخادم إلى وكيل المستخدم.
  • Date: الذي يوضح تاريخ إنشاء الرسالة.

HTTP Content Encoding ترميز المحتوى HTTP

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

في HTTP يشير deflate إلى تدفق DEFLATE داخل غلاف zlib. المقطع التالي يعرض بدائل؛ عند تطبيق أكثر من ترميز تسجل أسماؤها بالترتيب الذي طبقت به، وتفك بالترتيب العكسي. السطر الذي يبدأ // تعليق تعليمي وليس رأس HTTP.

Content-Encoding header pattern

تقنيات متعددة لضغط البيانات، تُطبق بتسلسل لتحسين حجم النقل وتقليل استهلاك النطاق الترددي.

نص 
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br
Content-Encoding: zstd

// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip

Compress content using gzip in HTTP response

يشير أن محتوى HTTP مضغوط بتقنية gzip لتقليل حجم البيانات المرسلة من الخادم إلى العميل.

نص 
Content-Encoding: gzip

HTTP Content Language لغة محتوى HTTP

لغة محتوى HTTP Content language تحدد لغة الجمهور المقصود للتمثيل؛ قد يحتوي النص نفسه لغات إضافية ولا تحصر كل كلمة موجودة فيه. تُساعد هذه التقنية في توجيه المستخدمين إلى نسخ من الصفحة تحتوي على محتوى بلغات مختلفة تناسب احتياجاتهم. تُحدّد اللغة باستخدام رموز مختصرة ومعروفة، مثل [en] للإنجليزية و[ar] للعربية، لغة المحتوي HTTP Content language تساعد في الوصول إلى المحتوى المناسب لكل مستخدم. .

Content-Language header pattern

عندما يتم تحديد لغة واحدة فقط.

نص 
Content-Language: <language-tag>

Content-Language header pattern

عندما تُحدّد أكثر من لغة.

نص 
Content-Language: <language-tag>, <language-tag>, <language-tag>

Select language: English

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

نص 
Content-Language: en

Target languages: German and English

يشير إلى أن الجمهور المستهدف للصفحة هم الأفراد الذين يتحدثون الألمانية والإنجليزية.

نص 
Content-Language: de, en

HTTP Content Location موقع محتوى HTTP

موقع المحتوى HTTP content location يحدد URI لتمثيل المحتوى المرفق بالرسالة، وقد يختلف عن URI المستهدف في الطلب؛ ليس مسار ملف على الخادم، يمكن تنزيل هذا المحتوى أو عرضه بفضل الخادم الذي يحتفظ بهذه البيانات، يُعدّ التعرف على المكان الذي تُحفظ فيه الملفات، وكيف يصلها المستخدم، خطوة هامة لفهم آلية الإنترنت بشكل أعمق.

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

Content-Location header pattern

يوضح العنوان Content-Location URI الذي يعرّف التمثيل المرفق، مثل نسخة لغة محددة؛ لا يأمر المتصفح بإعادة التوجيه.

نص 
Content-Location: <url>

Create your first blog using example.com API

طريقة إنشاء ونشر مقال جديد باستخدام واجهة برمجة تطبيقات النصوص من example.com.

نص 
POST /new/post HTTP/1.1
Host: example.com
Content-Type: text/markdown; charset=utf-8
Content-Length: 97

# My First Blog Post!

I created this using the API from `example.com`. I hope it was successful.

Create a new blog post via API successfully

يوضح المثال إنشاء منشور مدونة عبر API بنجاح برمز "201 Created" وموقع بتنسيق Markdown.

نص 
HTTP/1.1 201 Created
Content-Type: text/markdown; charset=utf-8
Location: /my-first-blog-post
Content-Location: /my-first-blog-post
Content-Length: 103

# My First Blog Post

I crafted this using the API provided by `example.com`. I hope it was successful.

Confirm successful payment of $38.00 to ExampleUser

استجابة HTTP ناجحة تؤكد إرسال مبلغ 38.00 دولارًا إلى ExampleUser، مع توفير تفاصيل الإيصال بتنسيق HTML.

نص 
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Location: /my-receipts/38

<!doctype html>
(Lots of HTML…)

<p>You sent $38.00 to ExampleUser.</p>

(Lots more HTML…)

HTTP Content Type نوع محتوى HTTP

نوع المحتوى HTTP content type يحدد نوع البيانات المتبادلة بين المستخدم والخادم. يُعرف من خلال رأس HTTP Content Type ويشمل صيغة البيانات مثل HTML أو JPEG. فهم نوع المحتوى يساعد في معالجة البيانات بشكل صحيح، مما يحسن تجربة المستخدم على الويب. يجب تعيين نوع المحتوى بشكل صحيح لضمان التوافق والأداء السهل عبر الأنظمة المختلفة.

Content-Type header pattern

نوع المحتوى: يُحدد نوع البيانات المتبادلة وكيفية معالجتها في HTTP.

نص 
Content-Type: <media-type>

Distinguishing between Data Types in HTTP

رأس Content-Type يُحدد نوع البيانات، والمعامل boundary داخل قيمة Content-Type من نوع multipart/form-data يحدد الفاصل؛ ليس رأسًا مستقلًا.

القيم أدناه بدائل مستقلة. JSON المتبادل بين الأنظمة يرمّز بـ UTF-8؛ لا يعرّف تسجيل application/json معامل charset.

نص 
Content-Type: application/json  
Content-Type: multipart/form-data; boundary=UniqueBoundaryString

HTTP Payload headers رؤوس الحمولة HTTP

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

قد تكون رؤوس الحمولة موجودة في رسائل الطلب والرد في HTTP أي في أي رسالة تحمل بيانات الحمولة،تشمل رؤوس الحمولة: طول المحتوى، نطاق المحتوى، العربة، وتركيبة الترميز.

في الطلب، يمكن لرأس الحمولة Content-Length تحديد طول الحمولة التي تم إرسالها في الطلب. بينما يمكن لرأس الحمولة Range يطلب نطاقات من المصدر، بينما Content-Range يصف موضع الجزء المرسل من التمثيل.

وفي رسالة الاستجابة، يعلن Trailer أسماء حقول سترد في القسم الختامي بعد الجسم؛ قيم الحقول تأتي في ذلك القسم، بينما يمكن استخدام Transfer-Encoding لتحديد الترميز المستخدم للنقل.

أنواع رؤوس الحمولة Payload Headers HTTP 


Content-Length: حجم المورد بالبايت.
Content-Range: يحدد مكان تواجد جزء من الرسالة الكاملة.

HTTP Representation Headers رؤوس التمثيل HTTP

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

من خلال رؤوس التمثيل Representation Headers، يستطيع الخادم إرسال توجيهات محددة لجعل عملية عرض البيانات أكثر فعالية وفعالية. يمكن لمطوري المواقع الاستفادة من هذه التوجيهات لضبط العرض والأداء بما يتناسب مع احتياجات المستخدمين.

أنواع رؤوس التمثيل Representation Headers HTTP

  • Content-Type: يحدد نوع الوسائط للمورد.
  • Content-Encoding: يُستخدم لتحديد خوارزمية الضغط.
  • Content-Language: يصف اللغة البشرية المخصصة للجمهور.
  • Content-Location: يشير إلى موقع بديل للبيانات المعادة.

HTTP Content Length طول محتوى HTTP

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

Content Size: Provide data in 219 bytes

Content-Length يُحدد حجم المحتوى بالبايتات.

نص 
Content-Length: 219

HTTP Content Range نطاق المحتوى HTTP

يشير رأس HTTP content range إلى جزء محدد من البيانات داخل ملف كامل، مما يساعد على نقل البيانات بشكل جزئي عبر الإنترنت بين الخوادم والمستخدمين.

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

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

Content Range header pattern

يحدد رأس Content Range نطاق البايت الدقيق الذي يتم إرساله في الاستجابة، وهو أمر مفيد لتنزيل أو بث أجزاء من ملف كبير.

نص 
Content-Range: <unit> <range-start>-<range-end>/<total-size>
Content-Range: <unit> <range-start>-<range-end>/*
Content-Range: <unit> */<total-size>

Specify the portion of data sent from the full file.

يحدد هذا النطاق نقل البيانات من البايت 300 إلى 1200 ضمن ملف حجمه الإجمالي 70,500 بايت.

نص 
Content-Range: bytes 300-1200/70500

HTTP Content Disposition توزيع المحتوى HTTP

يستطيع رأس HTTP content disposition على توجيه المتصفح في كيفية التعامل مع المحتوى المرسل من الخادم، مثل فتحه مباشرة أو تنزيله كملف. يمكن للمطورين استخدام إعدادات مثل attachment لتنزيل الملف أو inline لعرضه داخل المتصفح، مما يعزز تجربة المستخدم. فهم هذا الرأس يساعد في تخصيص تجربة إدارة الملفات على الويب، بتحديد كيفية عرض أو تنزيل المحتويات مثل الصور أو المستندات.

Content Disposition header pattern

أساسيات التعامل مع البيانات داخل المحتوى الرئيسي للنص.

نص 
Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="file_name.html"

Content Disposition header pattern

اساسيات التعامل مع البيانات المعقدة والمتنوعة في النصوص خطوة بخطوة.

نص 
Content-Disposition: form-data
Content-Disposition: form-data; name="field_value"
Content-Disposition: form-data; name="field_value"; filename="file_name.html"

HTTP Response: PDF download successfully

استجابة HTTP توفر مستند PDF للتنزيل بحجم 1024 بايت واسمه document.pdf.

يعرض المثال رؤوس الاستجابة فقط؛ بايتات ملف PDF غير مرفقة، فلا يمثل مستندًا كاملًا يمكن فتحه.

نص 
HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="document.pdf"
Content-Length: 1024

Upload user data and image using HTTP POST request.

يرسل مثال HTTP POST حقول نصية وملف عبر `multipart/form-data`.

الفاصل وكل أسطر أجزاء multipart مفصولة بـ CRLF، بما فيها السطر الأخير؛ يحسب Content-Length من هذه البايتات. newcontent نص بديل تعليمي لبايتات الملف، وليس صورة JPEG صالحة رغم الاسم profile.jpg.

نص 
POST /submit.html HTTP/1.1
Host: newsite.com
Content-Type: multipart/form-data; boundary="newboundary"
Content-Length: 204

--newboundary
Content-Disposition: form-data; name="username"

newuser123
--newboundary
Content-Disposition: form-data; name="profile_picture"; filename="profile.jpg"

newcontent
--newboundary--

HTTP WWW Authenticate مصادقة HTTP WWW

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

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

عملية المصادقة HTTP WWW-Authenticate تُستخدم لحماية الموارد والمعلومات القيمة من الوصول غير المصرح به.

WWW-Authenticate header pattern

سطر رأس HTTP يحدد نوع المصادقة والنطاق المطلوب للوصول إلى مورد.

نص 
WWW-Authenticate: <scheme> realm="<realm>"

Use the WWW-Authenticate line to authenticate a Bearer in the "secure-area" range

سطر رأس HTTP يحدد أن المصادقة المطلوبة هي من نوع Bearer للوصول إلى المورد ضمن المجال "secure-area".

نص 
WWW-Authenticate: Bearer realm="secure-area"

Implement Digest Authentication for secure access to the Admin Area.

سطر رأس HTTP يحدد استخدام Digest Authentication للوصول إلى "Admin Area" مع إعدادات أمان "qop" و"charset".

nonce هنا قيمة تعليمية؛ على الخادم توليد قيمة مناسبة لكل تحدٍّ والتحقق منها وفق RFC 7616، ولا تستخدم هذه القيمة الثابتة في نظام مصادقة. Digest لا يغني عن HTTPS ولا يشفّر جسم الرسائل.

نص 
WWW-Authenticate: Digest realm="Admin Area", nonce="dGVhY2hpbmctZXhhbXBsZQ==", algorithm=SHA-256, qop="auth", charset=UTF-8

HTTP Proxy Authenticate مصادقة وكيل HTTP

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

Proxy-Authenticate header pattern

نمط كود Proxy-Authenticate

نص 
Proxy-Authenticate: <type> realm=<realm>

Example of using Bearer token for proxy authentication

رمز مصادقة Bearer لتفويض الوصول عبر خادم وكيل.

نص 
Proxy-Authorization: Bearer zYXwVuT9876AbCdEf1234

HTTP Age رأس العمر HTTP

رأس المحتوى HTTP Age يعبر عن تقدير عمر الاستجابة بالثواني منذ توليدها أو آخر تحقق ناجح منها، وقد يشمل زمن الشبكة والإقامة في أكثر من مخزن مؤقت. إذا كان HTTP Age يحمل القيمة "0"، فلا يثبت أن الاستجابة جاءت مباشرةً من المصدر؛ قد تكون حديثة أو أعيد التحقق منها لدى مخزن مؤقت. في الحالات الأخرى، يحسب المخزن العمر وفق قواعد RFC 9111 التي تجمع العمر السابق وتأخير الاستجابة ومدة الإقامة، وليس مجرد طرح تاريخين دائمًا.

age header pattern

يشير "age: <delta-seconds>" إلى الوقت المنقضي، بالثواني، منذ توليد الاستجابة أو آخر تحقق ناجح منها، لا منذ آخر تعديل لنص المورد بالضرورة.

نص 
age: <delta-seconds>

Measure buffering time to improve responsiveness

المثال يوضح أن المحتوى المخزن مؤقتًا قد مر عليه ساعة من العمر المقدّر للاستجابة منذ التوليد أو آخر تحقق ناجح.

نص 
Age: 3600

HTTP Cache Control التحكم في ذاكرة التخزين المؤقت لـ HTTP

التخزين المؤقت HTTP Cache Control يحتوي على توجيهات تعليمات، تُستخدم في كل من الطلبات والاستجابات، للتحكم في التخزين المؤقت في المتصفحات والمخازن المؤقتة المشتركة مثل البروكسيات، والشبكات السحابية [CDNs].

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

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

Set content caching time to 1 hour in HTTP

يشير المثال أن المحتوى يمكن تخزينه لمدة ساعة واحدة قبل التحقق من صلاحيته مجددًا.

نص 
Cache-Control: max-age=3600

1 day cache duration with 200 seconds cache lifetime

يشيرالمثال أن المحتوى يمكن تخزينه مؤقتًا لمدة يوم واحد، وقد مضى 200 ثانية من فترة التخزين بالفعل.

نص 
Cache-Control: max-age=86400
Age: 200

Set a server cache duration of 5 days

يشير المثال أن المحتوى يمكن تخزينه مؤقتًا في ذاكرة التخزين المؤقت الوسيطة لمدة تصل إلى خمسة أيام [432000 ثانية].

نص 
Cache-Control: s-maxage=432000

Cache-Control no-cache header pattern

يتطلب التحقق من صلاحية المحتوى مع الخادم في كل مرة قبل استخدام النسخة المخزنة.

نص 
Cache-Control: no-cache

Content validity management with continuous verification after one hour

يُسمح للمتصفح بتخزين المحتوى لمدة ساعة، ثم يجب عليه إعادة التحقق من الصلاحية مع الخادم.

نص 
Cache-Control: max-age=3600, must-revalidate

Cache-Control no-store header pattern

يمنع المتصفح من تخزين أي نسخة من محتوى الصفحة لضمان الخصوصية والأمان.

نص 
Cache-Control: no-store

Cache-Control header pattern

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

نص 
Cache-Control: private

Cache-Control-public header pattern

يسمح بتخزين المحتوى مؤقتاً بواسطة أي مخبئ، مما يجعله متاحاً للعديد من المستخدمين لتحسين الأداء.

نص 
Cache-Control: public

Caching content for a day with maximum efficiency

يتيح تخزين المحتوى مؤقتًا من قِبل أي مستفيد لمدة يوم واحد (86400 ثانية) لتسريع الوصول وتحسين الأداء.

نص 
Cache-Control: public, max-age=86400

Safe storage instructions with mandatory support for directions

يشترط must-understand فهم متطلبات تخزين كود الحالة. المخزن الذي يفهمها ينبغي أن يتجاهل no-store المصاحب ويطبق تلك المتطلبات؛ أما الذي لا يفهم must-understand فيظل no-store مانعًا للتخزين. لا يمثل ذلك ضمانًا شاملًا للخصوصية.

نص 
Cache-Control: must-understand, no-store

Persistent content storage for one month to improve performance

يتيح تخزين المحتوى لمدة ثلاثين يومًا دون تغييرات، مما يعزز الأداء وكفاءة التحميل.

immutable يخص فترة الحداثة المحددة فقط؛ بعد انتهائها تعود قواعد التحقق المعتادة، ولا يجعل الملف ثابتًا إلى الأبد.

نص 
Cache-Control: public, max-age=2592000, immutable

Fast loading with asynchronous updating during grace period

يسمح بتخزين المحتوى لمدة ساعة مع استخدامه بشكل مؤقت لمدة 10 دقائق إضافية أثناء التحقق من تحديثات جديدة.

نص 
Cache-Control: max-age=3600, stale-while-revalidate=600

Flexible loading with temporary validity and persistence in case of errors

يسمح بتخزين المحتوى لمدة 12 ساعة مع استخدام النسخة القديمة لمدة ساعة إضافية في حالة حدوث خطأ في التحديث.

تبدأ نافذة stale-if-error بعد انتهاء الحداثة؛ لا تبدأ ساعة جديدة مع كل فشل. تشمل الأخطاء المسموح بها الحالات المحددة في RFC 5861.

نص 
Cache-Control: max-age=43200, stale-if-error=3600

HTTP Expires انتهاء صلاحية HTTP

انتهاء صلاحية HTTP Expires هو جزء من استجابات بروتوكول HTTP ويُستخدم لتحديد تاريخ انتهاء الصلاحية للمحتوى المخزن مؤقتًا في المتصفح، مما يساعد في تحسين سرعة تحميل الصفحات وتقليل استهلاك البيانات بإبقاء النسخ القديمة ما لم تنتهِ صلاحيتها. إذا كان يحتوي على الصفر [0]، فهذا يعني أن الاستجابة قد انتهت صلاحيتها بالفعل. ضبط هذه الخاصية بشكل صحيح يضمن تجربة استخدام أسرع ومتناسقة دون التسبب في عرض محتوى قديم.

القيمة 0 ليست تاريخ HTTP صالحًا، فتعامل كتاريخ مضى. عند وجود max-age يتقدم على Expires، ويتقدم s-maxage في المخازن المشتركة وفق قواعده.

Expires header pattern

نمط رأس Expires.

نص 
Expires: <http-date>

Specify the expiration date of cached content

تحديد تاريخ انتهاء صلاحية المحتوى المخزن مؤقتًا، مما يوجه المتصفح لاستخدام النسخة المخزنة حتى الوقت المحدد.

نص 
Expires: Fri, 01 Dec 2023 10:00:00 GMT

HTTP Location موقع HTTP

رأس HTTP Location يُستخدم لتحديد عنوان URL المراد التوجه إليه في حالات إعادة التوجيه أو إنشاء الموارد الجديدة. هذا العنوان يظهر مع أكواد استجابة مثل 3XX التي تشير إلى إعادة التوجيه، أو 201 Created للإعلان عن إنشاء مورد جديد، مما يتيح للعميل معرفة الموقع الجديد للمورد. تعتمد الطريقة المستخدمة في الطلب الجديد على الطريقة الأصلية ونوع إعادة التوجيه؛ مثلًا، 303 يشير إلى جلب المورد الآخر بـ GET أو HEAD، وقد يتحول POST إلى GET عند اتباع 301 أو 302؛ أما 307 و308 فيحافظان على الطريقة والجسم.

Location header pattern

نمط رأس Location

نص 
Location: <url>

Redirect page to internal address

المثال يشير إلى إعادة توجيه المستخدم إلى الصفحة الرئيسية في الموقع ضمن دليل home.

نص 
Location: /home/page.html

HTTP Connection اتصال HTTP

يعد رأس HTTP Connection أداةً تسمح للعميل بتحديد كيفية إدارة الاتصالات بالشبكة بسهولة، فبدلاً من فتح اتصال جديد لكل طلب، يُمَكّن الرأس من استخدام اتصال TCP واحد لإرسال واستقبال طلبات HTTP متعددة مما يساعد في تحسين الأداء وتقليل زمن الاستجابة. عندما تكون القيمة "keep-alive"، يبقى الاتصال مستمرًا. هذا يساعد في تحميل بيانات متعددة بفعالية دون إعادة إنشاء الاتصالات المتكررة، مما يجعل تجربة التصفح أسرع وأكثر كفاءة للمستخدمين.

الاتصال المستمر هو الافتراضي في HTTP/1.1 ما لم يطلب الإغلاق أو يوجد سبب آخر؛ keep-alive ليس ضمانًا لإبقاء الاتصال مفتوحًا. لا يرسل Connection أو Keep-Alive في HTTP/2 وHTTP/3.

Connection header pattern

المثال يوضح ان الاتصال في HTTP بين الإبقاء عليه مفتوحًا مع "keep-alive" أو إغلاقه بعد الطلب بـ"close".

نص 
Connection: keep-alive
Connection: close

HTTP persistence settings

المثال يشير ان max=200 تلميح في آلية Keep-Alive القديمة لحد عدد الطلبات؛ لا يضمن أن الخادم أو الوسيط سيحتفظ بالاتصال لكل هذه الطلبات.

نص 
Connection: keep-alive
Keep-Alive: max=200

HTTP connection closing settings

المثال يشير إلى إعداد HTTP حيث يُغلق الاتصال بعد تنفيذ الطلب الحالي مباشرةً.

نص 
Connection: close

HTTP Server خادم HTTP

يُعدّ عنوان الخادم في HTTP جزءًا من معلومات الاستجابة، حيث يحتوي على بيانات حول البرمجيات التي يستخدمها الخادم لمعالجة الطلبات. يُظهر هذا العنوان فقط بعض التفاصيل البسيطة عن الخادم، مثل اسم الخادم والبرمجيات مثل [sffe] و[cloudflare]، وتحدد إعدادات الخادم ما يرسله فعلًا. الرأس لا يخفي المعلومات تلقائيًا؛ يفضل تجنب كشف تفاصيل غير لازمة مع تحديث البرمجيات وضبط الوصول.

Server: [Product] as a reliable connection point for digital data and services

"<product> هو خادم ويب يقوم باستلام ومعالجة طلبات HTTP لتسليم الصفحات والمحتويات إلى المتصفح بكفاءة."

نص 
Server: <product>

Improve website performance and security with Cloudflare

المزود: كلاودفلير يحسّن سرعة الموقع وأمانه من خلال شبكة توزيع المحتوى ويقدم حلول حماية متقدمة ضد التهديدات الإلكترونية.

نص 
server: cloudflare

Server Performance Details Using Akamai Resource Optimizer

المثال يشير ان تم تسجيل "MISS" في تخزين المحتوى المخبأ للشبكة ومدة استجابة الحافة كانت 2 مللي ثانية.

نص 
server: Akamai Resource Optimizer
server-timing: cdn-cache; desc=MISS
server-timing: edge; dur=2

HTTP Timing-Allow-Origin السماح بالتوقيت-الأصل HTTP

تسمح خاصية السماح بالتوقيت الأصل Timing-Allow-Origin لمواقع الويب بتحديد من يمكنه رؤية معلومات عن سرعة تحميل العناصر على الموقع. هذه المعلومات مهمة لأنها تساعد في تحسين أداء الموقع، وجعل التصفح أسرع للمستخدمين. 

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

Timing-Allow-Origin header pattern

تسمح لجميع المواقع بالوصول إلى معلومات توقيت التحميل لتحليل أداء الموقع.

نص 
Timing-Allow-Origin: *

Timing-Allow-Origin header pattern

يسمح للمواقع المحددة فقط بالوصول إلى معلومات توقيت التحميل لتحسين الأداء.

نص 
Timing-Allow-Origin: <origin> [, <origin>]*

Allow CloseTag to access your download timing data

المثال يشير ان تم السماح فقط لموقع "https://www.closetag.com" بالوصول إلى معلومات توقيت التحميل لتحليل أداء الموقع.

نص 
Timing-Allow-Origin: https://www.closetag.com

HTTP Content-Security-Policy سياسة أمان محتوى HTTP

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

CSP طبقة دفاع إضافية وليست علاجًا لكل ثغرة. default-src بديل لتعليمات الجلب الغائبة، والتعليمة الأكثر تحديدًا مثل script-src تضبط نوعها. لا تستخدم نقطتين بعد اسم التعليمة داخل القيمة.

Content-Security-Policy header pattern

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

نص 
Content-Security-Policy: <policy-directive>; <policy-directive>

CloseTag Content Security Policy: Identifying Safe Sources and Controlling Communications

تحدد هذه الخاصيه المصادر المسموح تحميلها من الموقع https://www.closetag.com، مع منع الاتصالات الخارجية الأخرى.

connect-src هنا يمنع اتصالات السكربت مثل fetch وWebSocket إلى جميع الوجهات؛ لا يمنع جلب ملفات script المسموح بها في script-src. هذا مثال تعليمي وليس وصفًا لسياسة الموقع الحالية.

نص 
Content-Security-Policy: default-src 'self' https://www.closetag.com; connect-src 'none'; script-src https://www.closetag.com

Content Security Policy for CloseTag Resources, Images and Scripts

تحميل الموارد من موقع CloseTag والصور والنصوص البرمجية من مواقعها المخصصة.

نص 
Content-Security-Policy: default-src 'self' https://www.closetag.com; img-src https://images.example.com; script-src 'self' https://scripts.example.com

Content Security Policy for CloseTag Resources, Images and Scripts

تحميل الموارد من موقع CloseTag والصور والنصوص البرمجية من مواقعها المخصصة.

نص 
Content-Security-Policy: default-src 'self' https://www.closetag.com; img-src https://images.example.com; script-src 'self' https://scripts.example.com

Set up a Content Security Policy (CSP) reporting endpoint

هذا المثال يحدد نقطة نهاية للإبلاغ عن انتهاكات سياسة أمان المحتوى (CSP) باستخدام نطاق مخصص.

يربط report-to السياسة باسم النقطة المعلن في Reporting-Endpoints. النطاق عنوان بديل وليس خدمة تقارير مهيأة؛ يتطلب استقبال التقارير خادمًا ودعمًا من المتصفح، وقد تختلف آلية الإرسال حسب دعمه.

نص 
Reporting-Endpoints: csp-endpoint="https://your-custom-domain.com/csp-reports"
Content-Security-Policy: default-src 'self'; report-to csp-endpoint

HTTP Strict-Transport-Security أمان النقل الصارم لـ HTTP

بروتوكول "فرض النقل الآمن عبر HTTP" المعروف بـ [HTTP Strict Transport Security أو HSTS] هو أداة أمان مصممة لحماية اتصالات المستخدم عبر الإنترنت عن طريق إجبار المتصفح على استخدام بروتوكول [HTTPS] فقط. يقوم مالك الموقع بتفعيل هذا البروتوكول من خلال إرسال تعليمات خاصة للمتصفح لضمان أن جميع الاتصالات المستقبلية تتم عبر [HTTPS]، مما يمنع احتمالية التحايل وسرقة البيانات. هذا يُعزز الحماية ضد هجمات مثل هجمات الاكترونية ويضمن أن البيانات تنتقل عبر قنوات آمنة. لتحقيق أقصى استفادة من [HSTS]، يجب التأكد من أن الموقع يعمل بكفاءة تحت بروتوكول [HTTPS] وأن جميع الروابط والمصادر تشير إليه فقط، مما يعزز ثقة المستخدمين في أمان الموقع.

يقبل المتصفح HSTS من استجابة HTTPS صحيحة فقط. الزيارة الأولى عبر HTTP قد تبقى معرضة ما لم توجد سياسة معروفة مسبقًا، مثل إدراج ملائم في قائمة preload. includeSubDomains يلزم تهيئة HTTPS لكل النطاقات الفرعية المشمولة.

Strict-Transport-Security header pattern

يوضح الإعدادات لـ Strict-Transport-Security، مع تعيين مدة الالتزام بـ HTTPS ويشمل النطاقات الفرعية وخيار التحميل المسبق.

نص 
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload

Set up strict security policy for transfers including subdomains for 6 months

يوضح المثال أن الموقع يُلزم المتصفح باستخدام HTTPS لمدة 15768000 ثانية [حوالي 6 أشهر] لجميع النطاقات الفرعية أيضًا لتعزيز الأمان.

نص 
Strict-Transport-Security: max-age=15768000; includeSubDomains

Enforce secure transfer with support for subdomains and preloading

يوضح المثال أن الموقع يُلزم المتصفح باستخدام HTTPS لمدة 31536000 ثانية [365 يومًا] لجميع النطاقات الفرعية أيضًا لتعزيز الأمان.

إضافة preload وحدها لا تضيف الموقع إلى قائمة المتصفحات؛ يلزم استيفاء شروط خدمة التسجيل وطلب الإدراج والتحقق منه. لا تفعل includeSubDomains قبل التأكد من جاهزية جميع النطاقات الفرعية.

نص 
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

مشاركة

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

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