yslow إعطاء نتائج غير متسقة على etags

Question

عندما أقوم بتشغيل yslow على موقعي ، أحصل على "F" على عنصر "تكوين etags" ؛ يدعي أنه لا توجد etags للعديد من (الكل؟) من صوري ، أوراق الأنماط ، إلخ.

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

هل هناك شيء قد أفعله للتسبب في هذا السلوك الغريب؟

(عناوين URL التي أضربها هنا و هنا إذا كان أي شخص يريد التحقق من نفسه. لا أمانع في التحقق من العقل لمعرفة ما إذا كان متصفحي هو مجرد مشوش.)

Answer 1

لقد جربت هذا محليًا مع FF 3.6 و YSLOW 2.0.3 (الإصدار الذي تم إصداره حديثًا) وتوفر الصورة المستقلة درجة من "B" ، مستشهدة بـ ETAGs الخاطئة.

تظهر ETAG في الرأس ، في لوحة Firebug Net وفي لوحة مكونات Yslow.

ولكن ، هذا حسب التصميم. إذا نظرت إلى http://developer.yahoo.com/performance/rules.html#etags سترى أن ETAGs الافتراضية التي تم إنشاؤها بواسطة IIS و Apache ليست مثالية.

للإشارة ، فإن قاعدة الوبر الفعلية في YSLOW تتحقق من اثنين من regexes التالية:

  apache_re = new RegExp("^[0-9a-z]+-[0-9a-z]+-[0-9a-z]+$");
  iis_re = new RegExp("^[0-9a-z]+:[0-9a-z]+$");

Answer 2

جوابي ، فيما يتعلق بـ IIS 7 ، هو تجاهل توصية Yslow.

يستخدم IIS 7 عدد تغيير الأيض من الصفر عند إنشاء ETAG. هذا هو الجزء الذي يتبع القولون ... لذلك سيكون ETAG دائمًا مثل "5321116d3585ce1: 0" ، حيث يتم إنشاء الجزء الأول من آخر وقت في الملف المعدل ، ثم رقم تغيير القولون والناشط.

بدءًا من IIS 7 ، قامت Microsoft بتعيين الرقم هذا إلى الصفر طوال الوقت ، لذلك سيكون هو نفسه حتى عبر خوادم ويب متعددة. بالنسبة إلى IIS 5 و 6 ، يمكنك ضبطه على الصفر إذا كنت ترغب في تحقيق نفس النتيجة النهائية:

http://technet.microsoft.com/en-us/library/EE619764(WS.10).aspx

إذا كان yslow لا يزال يستخدم قاعدة regex من IIS_RE = جديد regexp ("^[0-9a-z]+: [0-9a-z]+$") ؛ بعد ذلك ، هم مخطئون ، ويجب إعادة كتابته لقبول ETAG على أنه صالح إذا انتهى به الأمر :0