هل يتسبب ترحيل ASP الكلاسيكي - IIS 5 إلى IIS 6 في حدوث مشكلات في التخزين المؤقت للصور؟

StackOverflow https://stackoverflow.com/questions/304749

  •  08-07-2019
  •  | 
  •  

سؤال

أعتذر مقدمًا عن السؤال الطويل.

أنا بالفعل مبرمج قواعد بيانات، ولكني ورثت دعم تطبيق إنترانت الكلاسيكي ASP والذي تم ترحيله مؤخرًا من IIS 5 إلى خادم جديد يقوم بتشغيل IIS 6.تبلغ قاعدة المستخدمين حوالي اثني عشر، كلهم ​​يستخدمون IE 6.

تعرض واجهة المستخدم تسلسلات هرمية للعناصر التي تم إرجاعها من قاعدة بيانات، باستخدام مجموعة من قوائم HTML غير المرتبة وجافا سكريبت لإخفاء/توسيع الفروع أثناء تنقل المستخدم.

يتم عرض الصور بجوار أعضاء القائمة باستخدام CSS (باستخدام صورة نمط القائمة)، باستخدام صورة مختلفة لكل نوع من العناصر.يتراوح عدد أنواع العناصر المختلفة (وبالتالي الصور) في التسلسل الهرمي بين 2 و10.تتراوح التسلسلات الهرمية بين 20 و200 عنصر.

المشكلة:

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

يوضح تحليل حركة مرور الشبكة باستخدام سجلات Wireshark وIIS أن المشكلة ليست من جانب الخادم - فقد تم توفير كل المحتوى بشكل صحيح للعميل.

يبدو أن المشكلة مرتبطة بالتخزين المؤقت للمحتوى لدى العميل:ويبدو أنه يؤثر في كثير من الأحيان على المستخدمين الذين لم يستخدموا التطبيق من قبل على أجهزة الكمبيوتر الحالية الخاصة بهم، أو لم يستخدموه لبعض الوقت.يمكنني أيضًا تكرار المشكلة مرة واحدة تقريبًا في ثلاث محاولات عن طريق بدء الجلسة ومسح ذاكرة التخزين المؤقت للمتصفح ثم تحديث الصفحة.ومع ذلك، ينطبق الأمر نفسه على التطبيق عند تشغيله على IIS 5، لذلك قد تكون هذه المشكلة موجودة قبل الترحيل إلى IIS 6 ولكنها حدثت بشكل أقل تكرارًا.في بعض الأحيان، إذا تركت الجلسة لمدة 20 دقيقة أو نحو ذلك، يبدو أن المتصفح "يعثر" على الصور المفقودة، وكل شيء يعمل على ما يرام.

إذا تم الوصول إلى التطبيق من خلال وكيل محلي (لقد استخدمت Fiddler)، فلن تحدث المشكلة أبدًا، على الرغم من أن سجل اتصال Fiddler يُظهر أنه تم إحباط اتصال واحد أو أكثر تم إجراؤه بالخادم لاسترداد الصور.كما كان من قبل، تُظهر حركة مرور الشبكة أن الصورة قد تم إرجاعها بواسطة الخادم.ومع ذلك، يبدو أن استخدام الوكيل يمكّن IE من العثور على نسخ أخرى من الصورة تم استردادها بنجاح من ذاكرة التخزين المؤقت.

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

أي اقتراحات حول كيفية المضي قدمًا سيتم تلقيها بامتنان.

يحرر

يقترح AnonJr أن هذه يجب أن تكون مشكلة في تكوين العميل، حيث يبدو أن جميع المكونات الأخرى تعمل بشكل صحيح.

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

ما هي خيارات تكوين العميل الأخرى التي يجب أن أفكر فيها؟

تحرير 2 - الحل

دفعتني الإجابة المقبولة إلى البحث عن مشكلة معروفة في IE6 التي تطلب نسخًا متعددة من الصور عند إنشاء HTML من البرنامج النصي من جانب العميل - http://support.microsoft.com/default.aspx?scid=kb;en-us;319546.

تقترح المقالة (التي ذكرت أن هذا السلوك "حسب التصميم") حلاً بديلاً للتخزين المؤقت المسبق للصور المطلوبة عن طريق تحميلها في ملف DIV غير مرئي:

<DIV style='display:none'><IMG SRC='image.gif'></DIV>

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

لقد وجدت تحذيرًا واحدًا لم أكن على علم به من قبل؛تعد ذاكرة التخزين المؤقت في IE حساسة لحالة الأحرف، لذلك لن يتم استخدام الصورة المخزنة مؤقتًا إلا إذا كانت حالة اسم الملف المحدد في DIV غير المرئية تتطابق مع تلك المستخدمة في أي مكان آخر في الصفحة.

هل كانت مفيدة؟

المحلول

يشير هذا إلى وجود خطأ في IE6 حيث يقوم المتصفح بتقديم طلبات متعددة لنفس المورد.على سبيل المثال، إذا كان المحتوى يتطلب عرض رمز صغير يتكرر 20 مرة في القائمة، فبدلاً من جلب تلك الصورة مرة واحدة فقط، فإنه يحاول جلبها 20 مرة.حسنًا، 19 من الردود هي 304 غير معدلة ولكن لا يزال هناك 19 رحلة ذهابًا وإيابًا إضافية إلى الخادم.

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

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

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

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

نصائح أخرى

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

قد يعمل الوكيل على تخفيف بعض المشكلات، و/أو قد يكون عاملاً في كيفية اتخاذ IE6 قرارًا بتخزين الصور مؤقتًا، وما إلى ذلك.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top