كل الأدوات

البحث عن رؤوس HTTP

استرجع جميع رؤوس HTTP التي يتم إرجاعها بواسطة عنوان URL لطلب GET نموذجي باستخدام أداة البحث عن رؤوس HTTP الخاصة بنا.

5 من 2 تقييمات
البحث عن رؤوس HTTP

البحث عن رؤوس HTTP أداة مجانية تسترجع جميع رؤوس استجابة HTTP التي يعيدها عنوان URL عند إرسال طلب GET اعتيادي.

ما رؤوس استجابة HTTP؟

رؤوس استجابة HTTP هي بيانات وصفية يرسلها خادم الويب قبل نص الاستجابة، مثل صفحة HTML أو صورة أو مستند JSON. وهي توضّح للعميل كيفية تفسير الاستجابة أو تخزينها مؤقتا أو إعادة توجيهها أو تأمينها.

تبدأ استجابة HTTP/1.x عادة بسطر حالة HTTP، ثم تأتي الرؤوس. أما في HTTP/2 وHTTP/3، فتُنقل الحالة المكافئة في الرأس الزائف :status. من الناحية التقنية، سطر حالة HTTP/1.x منفصل عن الرؤوس، لكنه يُعرض معها عادة لأنه يبيّن ما إذا كان الطلب قد نجح. فالحالة 200 تعني إعادة المورد، وتشير 301 أو 302 إلى إعادة توجيه، وتعني 404 أن المورد غير موجود، بينما تشير 500 إلى خطأ من جهة الخادم.

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

رسم توضيحي: طلب موجه إلى الخادم يعيد رؤوس استجابة HTTP

كيف أبحث عن رؤوس HTTP؟

أدخل عنوان URL الكامل الذي تريد فحصه، بما في ذلك المخطط، مثل https://www.example.com/account. ترسل الأداة طلب GET اعتياديا من خادمها، ثم تعرض رؤوس HTTP المستلمة من ذلك العنوان.

لمقارنة رؤوس الاستجابة بدقة، استخدم صيغ عناوين URL نفسها التي تريد فحصها. فقد تختلف رؤوس http://example.com وhttps://example.com وhttps://www.example.com لأن لكل عنوان عمليات إعادة توجيه وقواعد تخزين مؤقت وإعدادات خادم خاصة به.

تؤثر صياغة عنوان URL أيضا في الطلب:

  • لا تصلح المسافات كأحرف خام داخل عنوان URL، ويجب عادة ترميزها بالنسبة المئوية، وغالبا بصيغة %20 ضمن المسار.
  • تبدأ علامة ? مكوّن الاستعلام، بينما تُستخدم & و= عادة في ترميز الاستعلامات المشابهة للنماذج، لكنهما لا تؤديان هذين الدورين في كل سلسلة استعلام.
  • تُعالج أسماء النطاقات التي تحتوي على أحرف مشكّلة أو غير لاتينية باستخدام IDNA، وتُمثّل على هيئة تسميات ASCII تبدأ عادة بـ xn--، بينما تُرمّز أحرف المسار عموما إلى بايتات UTF-8 ثم تُرمّز بالنسبة المئوية.
  • يتعامل المتصفح مع الجزء الذي يبدأ بـ #، ولا يرسله ضمن طلب HTTP.
  • لا يوجد حد أقصى موحّد لطول عنوان URL. وقد يرفض الخادم أو الوكيل أو التطبيق العناوين الطويلة جدا.
أداة البحث عن رؤوس HTTP على digily.link مع نموذج الإدخال

كيف أقرأ نتيجة رؤوس HTTP؟

افحص الرؤوس المرتبطة بالمشكلة التي تحاول تشخيصها. أسماء الرؤوس غير حساسة لحالة الأحرف، لكن صياغة قيمها قد تكون حساسة لها.

حقل النتيجة ما الذي يوضحه؟
Location وجهة إعادة التوجيه. ويأتي عادة مع حالة من فئة 3xx.
Content-Type نوع الوسائط المُعاد، مثل text/html أو application/json أو image/png.
Content-Length الحجم المعلن لنص الاستجابة بالبايت، عندما يرسله الخادم. وقد تغفله الاستجابات المجزأة أو المُنشأة ديناميكيا.
Cache-Control and Expires تعليمات التخزين المؤقت ووقت انتهاء صلاحية الاستجابة، إن كان محددا.
Age العمر المحسوب للاستجابة المخزنة مؤقتا منذ إنشائها أو آخر تحقق منها، وقد يشمل الوقت الذي قضته في ذاكرات التخزين المؤقت السابقة، ويُقاس بالثواني.
ETag and Last-Modified أدوات تحقق يمكن للعملاء استخدامها لمعرفة ما إذا كان المحتوى المخزن مؤقتا قد تغيّر.
Set-Cookie طلب لتخزين ملف تعريف ارتباط، مع سمات مثل Secure وHttpOnly وSameSite.
Content-Security-Policy قواعد للمتصفح تقيّد النصوص البرمجية والأنماط والإطارات والموارد الأخرى التي يمكن للصفحة تحميلها.
Strict-Transport-Security تعليمة تطلب من المتصفحات المتوافقة استخدام HTTPS طوال المدة المحددة.

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

مثال على نتيجة أنتجتها أداة البحث عن رؤوس HTTP

سيناريوهات عملية لاستكشاف الأخطاء

تُعد مشكلات إعادة التوجيه من الأسباب الشائعة لفحص الرؤوس. لنفترض أن https://example.com/old-page يعيد الحالة 301 مع Location: https://example.com/new-page. هذا يعني أن الخادم يطلب من العميل إرسال طلب إلى العنوان الجديد. ويمكن أن تكشف إعادة فحص كل وجهة عن حلقة إعادة توجيه أو انتقال غير متوقع بين HTTP وHTTPS.

إذا ظهرت صفحة قديمة خلف Cloudflare أو شبكة CDN أخرى، فافحص Cache-Control وAge وETag وأي رأس تخزين مؤقت خاص بمزوّد الخدمة. تشير القيمة الكبيرة في Age إلى العمر المحسوب للاستجابة المخزنة مؤقتا، وقد يشمل الوقت الذي قضته في ذاكرات التخزين المؤقت السابقة، وليس إلى مدة احتفاظ وسيط معين بها. كما أنها لا تثبت أن جميع ذاكرات التخزين المؤقت الإقليمية تحتفظ بالإصدار نفسه.

عندما تعمل واجهة API في برنامج نصي من جهة الخادم لكنها تفشل في المتصفح، افحص Content-Type ورؤوس استجابة CORS، ومنها Access-Control-Allow-Origin. إذا أعادت نقطة نهاية JSON القيمة text/html، فقد تكون في الواقع تعرض صفحة خطأ أو شاشة تسجيل دخول. وقد يؤدي غياب إذن الوصول المشترك بين الأصول إلى منع المتصفح من الوصول، حتى إذا أعاد الخادم الحالة 200.

يمكن أن تساعد الرؤوس أيضا عند فحص موقع يبدو غير متاح. تشير استجابة 503 إلى عطل مؤقت في الخادم أو في خدمة سابقة له، بينما تعني 404 أن المسار المطلوب غير موجود. لكن الرؤوس لا تستطيع تشخيص كل الأعطال. فإذا فشل حل DNS أو اتصال TCP أو تفاوض TLS قبل إنشاء استجابة HTTP، فقد لا تتوفر أي رؤوس استجابة لفحصها. يوفّر بنغ فحصا منفصلا للاتصال، بينما يستطيع مدقق HTTP/2 التحقق من دعم البروتوكول.

لماذا قد تبدو نتيجة الرؤوس الصحيحة غير صحيحة؟

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

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

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

الأسئلة الشائعة

هل تعرض الأداة رؤوس الطلب؟

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

هل عناوين URL التي أدخلها في الأداة خاصة؟

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

هل يمكن لرؤوس HTTP تفسير تحذير الشهادة؟

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

لماذا تظهر عدة رؤوس Set-Cookie؟

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

هل يمكنني مقارنة النتيجة مع curl؟

نعم. يطبع أمر مثل curl -D - https://example.com/ -o /dev/null رؤوس الاستجابة ويتجاهل نصها. قد تؤدي إصدارات Curl المختلفة ورؤوس الطلب وإعدادات إعادة التوجيه ومواقع الشبكة إلى نتائج مختلفة، لذا طابق هذه الظروف قبل اعتبار أي اختلاف عطلا في الخادم.

مشاركة

الأدوات الشائعة