التحكم في ذاكرة التخزين المؤقت للمتصفح ، المحتوى الديناميكي

Question

مشكلة: لا يبدو لي أن أحصل على صور فايرفوكس إلى ذاكرة التخزين المؤقت المرسلة من خادم ديناميكي

اقامة: خادم apache ثابت مع وكيل عكسي لخادم ديناميكي (mod_perl2) في الخلفية.

هنا هو عنوان URL لطلب الخادم. يتم إرساله إلى الخادم الديناميكي ، حيث يتم استخدام ملف تعريف الارتباط للتحقق من صحة الوصول إلى الصورة:

طلب الرؤوس

Host:  <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Pragma:  no-cache
Cache-Control: no-cache

يقوم الخادم الديناميكي بتدفق الصورة مرة أخرى إلى الخادم ، ويوفر الاستجابة التالية:

رؤوس الاستجابة

Date:  Tue, 24 Nov 2009 04:28:07 GMT
Server:  Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Cache-Control: public, max-age=31536000
Content-Length:  25496
Content-Type:  image/jpeg
Via: 1.1 127.0.1.1:8081
Keep-Alive:  timeout=15, max=75
Connection:  Keep-Alive

حتى الآن ، جيد جدًا (أعتقد). لكن، عند إعادة تحميل الصفحة, ، لا تظهر الصورة مؤقتًا ، ويتم إرسال الطلب مرة أخرى:

طلب الرؤوس

Host: <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Cache-Control: max-age=0

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

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

هل يعلم اي احد لماذا حصل هذا؟ ربما هو عبر رأس في الاستجابة التي تسبب المشكلة؟

Answer 1

كانت إجابتي السابقة صحيحة جزئيًا فقط.

المشكلة هو الطريق Firefox 3 مقابض أحداث إعادة التحميل. على ما يبدو ، يطلب دائمًا المحتوى مرة أخرى من خادم Origin. وهكذا Cache-Control: max-age=0 طلب رأس.

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

لذلك ، تقوم الصفحة بإعداد سريع ، تقارير YSLOW المحتوى المخبوق. لكن الخادم لا يزال مسمرًا.

الحل هو استجواب الرؤوس الواردة في البرنامج النصي الخادم الديناميكي وتحديد ما إذا كان يتم توفير رأس "IF-modive-since". إذا كان هذا هو الحال ، وتم تحديده لم يتغير المحتوى ، يتم إرجاع استجابة http_not_modified (304).

هذا ليس الأمثل - أفضل عدم تقديم الطلبات على الإطلاق - لكنه يقطع وقت تحميل الصفحة إلى النصف ، ويقلل إلى حد كبير النطاق الترددي. بالنظر إلى طريقة عمل Firefox على إعادة التحميل ، يبدو هذا أفضل حل.

تعليقات أخرى: نقطة جيم فيران حول التنقل بعيدًا عن الصفحة والعودة لها ميزة - يتم استخدام ذاكرة التخزين المؤقت دائمًا ، ولا توجد طلبات صادرة (+1 إلى جيم). أيضًا ، يبدو أن المحتوى الذي يتم إضافته ديناميكيًا (مثل مكالمات Ajax بعد التحميل الأولي) يستخدم ذاكرة التخزين المؤقت أيضًا.

آمل أن يساعد هذا شخص ما بجانبي :)

Answer 2

الطلب الأصلي لديه

Cache-Control: no-cache

الذي يخبر جميع ذاكرة التخزين المؤقت لـ HTTP المتوسطة (بما في ذلك Firefox) أنك لا ترغب في استخدام استجابة مخزنة مؤقتًا ، فأنت تريد الحصول على الاستجابة من خادم الويب Origin نفسه.

الرد يقول:

Cache-Control: public, max-age=31536000

الذي يخبر الجميع أنه فيما يتعلق بخادم الأصل ، فإن الرد مايو كن مخبأة. يبدو أن الخادم تم تكوينه لتمكين صورة PNG ليتم تخزينها مؤقتًا: http 1.1 (القسم 14.21) يقول:

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

طلبك الثاني يقول:

Cache-Control: max-age=0

الذي يخبر جميع ذاكرة التخزين المؤقت لـ HTTP المتوسطة بأنك لن تأخذ أي استجابة مخزنة بأكبر من 0 ثانية.

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

راجع للشغل ، أنا أحب Firebug Plug-in for Firefox. يمكنك إلقاء نظرة على رؤوس الطلب والاستجابة معها وجميع أنواع الأشياء الجيدة الأخرى.

Answer 3

يبدو أن حلها:

• أزال الوكيل عبر الرأس
• أضاف رأسًا آخر معدل
• أضاف تاريخ انتهاء صلاحيته بعيدة

لا يزال Firebug يعرض 200 ردود من خادم Origin ، ومع ذلك ، يتعرف Yslow على الصور على أنها مخزنة مؤقتًا. وفقًا لـ yslow ، فإن حجم تنزيل الصورة الكلي عندما يكون طازجًا أكبر من 500 ألف ؛ مع Cache Preped ، فإنه يظهر حجم التنزيل 0K.

هنا هو رأس الاستجابة من خادم Origin الذي يقوم بالخدعة:

Date: Tue, 24 Nov 2009 08:54:24 GMT
Server: Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Last-Modified: Sun, 22 Nov 2009 07:28:25 GMT
Expires: Tue, 30 Nov 2010 19:00:25 GMT
Content-Length: 10883
Content-Type: image/jpeg
Keep-Alive: timeout=15, max=89
Connection: Keep-Alive

بسبب الطريقة التي أطلب بها الصور ، لا ينبغي أن يهم حقًا إذا كانت هذه التواريخ ثابتة ؛ يعرف تطبيقي آخر وقت التعديل قبل طلب الصورة وإلحاق هذا بعنوان URL على جانب العميل لإنشاء عنوان URL فريد لكل إصدار صورة ، على سبيل المثال http://myserver.com/img/125.jpg؟20091122 (المعلومات تأتي من خلاصة Ajax JSON). يمكنني ، على سبيل المثال ، إجراء آخر تاريخ تم تعديله في 01 يناير 2000 ، وتاريخ انتهاء الصلاحية في وقت ما في عام 2050.

إذا كان YSLOW صحيحًا - واختبار الأداء يعني أنه - فيجب على Firebug الإبلاغ حقًا عن هذه الأغاني المحلية بدلاً من استجابة 200.