HAR Files لتشخيص مشاكل الويب: ماذا تقرأ قبل مشاركة الملف

ملف HAR مفيد لأنه يجمع network timeline في سجل يمكن مراجعته خارج جلسة المتصفح. لكنه ليس مجرد قائمة URLs؛ قد يحتوي headers و query strings و request bodies و responses. لذلك يجب فهم ما تقرأه وما قد تكشفه قبل إرساله إلى دعم أو طرف ثالث.

ابدأ بالطلب الفاشل وسياقه

ابحث عن status غير متوقع أو request ظل pending. راجع initiator وال redirect chain والطلب السابق. خطأ واحد قد يكون نتيجة redirect أو preflight فاشل قبله.

اقرأ Timing breakdown

DNS و connect و SSL و wait/TTFB و receive توضح مكان الزمن. لا تفسر wait طويلًا كشبكة بطيئة مباشرة؛ قد يكون server processing. قارن بطلب ناجح لنفس host.

افحص Headers بحذر

Authorization و Cookie و Set-Cookie و CSRF headers حساسة. عند التشخيص المحلي يمكن قراءتها، لكن قبل مشاركة HAR احذف القيم. query قد تحتوي token أيضًا.

قارن Request و Response

تأكد من method و content-type و origin و referer عند الحاجة. 400 قد يأتي من payload، 401 من auth، 403 من policy، 429 من rate limiting. اقرأ response body إذا آمن.

استخدم Filter حسب domain ونوع

ملفات HAR الكبيرة تحتوي analytics و images. ابدأ ب ـXHR/fetch أو host المستهدف لتقليل الضوضاء، ثم وسع النطاق إذا suspect third-party dependency.

شارك نسخة منقحة فقط

احتفظ بالأصل محليًا إن كان مسموحًا وأنشئ sanitized copy. افتحها كنص وابحث عن token و email و cookie names قبل الإرسال. لا تعتمد على أن أداة export حذفت الأسرار تلقائيًا.

استخدم HAR Comparison بدل قراءة ملف واحد بمعزل

خذ HAR من تشغيل ناجح وآخر فاشل بنفس الخطوات والبيئة قدر الإمكان، ثم قارن عدد الطلبات وترتيبها وال ـstatus والتوقيت وال headers المهمة بعد redaction. الفرق بين الملفين غالبًا أسرع من قراءة عشرات الطلبات بلا baseline. راقب هل طلب معين اختفى، هل redirect جديد ظهر، أو هل connect/TLS time قفز على domain واحد. ويمكن بناء أداة صغيرة تلخص الفروق بدل مشاركة الملفين كاملين. إذا كان البروفايل يستخدم Proxy، سجّل نوع البروكسي وعنوان الخروج خارج HAR في metadata حتى لا تخلط تغير الشبكة مع تغير التطبيق. المقارنة المنظمة تجعل HAR أداة regression مفيدة بعد تحديث Chromium أو Proxy Manager، لا ملفًا يفتح فقط عند حدوث عطل.

استخدم HAR مع Server Logs عند الإمكان

HAR يريك جانب العميل فقط. أضف Correlation ID أو timestamp يسمح بربط الطلب بسجل الخادم أو reverse proxy. عند 502 مثلًا، HAR لا يوضح دائمًا هل upstream timeout أم connection reset. الجمع بين الطرفين يحدد الطبقة بسرعة. إذا لم تملك الخادم، سجل على الأقل request ID من response headers ليستخدمه فريق الخدمة في البحث.

من المثال إلى تطبيق يمكن صيانته

في «HAR Files لتشخيص مشاكل الويب: ماذا تقرأ قبل مشاركة الملف» جرّب الحل على حالة صغيرة ثم أضف failure path واضحًا واختبارًا آليًا يحمي السلوك المتوقع. حدّد contract للمدخلات والمخرجات، وتعامل مع القيم الناقصة قبل الوصول إلى طبقة التنفيذ. إذا كان الحل يتعامل مع API أو ملف أو DOM، أضف logging مختصرًا يوضح المرحلة وكود الخطأ دون بيانات حساسة. بعد ذلك اختبر التوافق مع نسخة سابقة أو بيئة مختلفة. هذه الخطوات تجعل المثال مفيدًا في مشروع حقيقي بدل أن يبقى snippet يعمل فقط في المسار المثالي.