تكوين الحبار لضمان مطابقة رأس HTTP مع المحتوى المخبوق

Question

لدينا إعداد سحابة مثل هذا:

User Request -> Perlbal (SSL unwrapping) -> Squid (Caching) -> Apache -> HTTP Response

نحن ندعم SSL على بعض الصفحات ، وليس على الآخرين. كل شيء خارج طبقة Perlbal لا يطلب فقط طلبات HTTP غير المشفرة منذ أن قام Perlbal بإلغاء SSL ، لكنه يضيف ملف X-Forwarded-Proto رأس بحيث يعرف التطبيق ما إذا كان SSL قد تم استخدامه أم لا.

إذا ضرب الطلب التطبيق (Apache) عبر HTTP ، عندما تتطلب تلك الصفحة المحددة SSL ، فإنه يعيد التوجيه إلى HTTPS.

عندما يصل طلب الحصول على مورد آمن إلى تطبيقنا ، وإذا أرسل التطبيق Cache-Control: public, ، مخابرات الحبار التي المحتوى بشكل صحيح. المشكلة هي أنه إذا حاول المستخدم بعد ذلك الوصول إلى إصدار HTTP من هذا المورد بمجرد أن يتم تخزينه مؤقتًا ، فإن الحبار يعالجه كضرب ذاكرة التخزين المؤقت وإرجاع المورد المخزنة عبر HTTP ، في حين نحتاج في الواقع إلى اعتباره ذاكرة التخزين المؤقت لأن ذاكرة التخزين المؤقت -لا يتطابق Proto-Proto مع الطلب الأصلي.

كيف يتم هذا؟ يرسل طلبنا:

Vary: X-Forwarded-Proto,Accept-Encoding

أواجه صعوبة في العثور على أي مقالات/وثائق حول هذا الأمر ويبدو أن هذا الرأس المتغير هو ما يقترحه الآخرون ، لكنه لا يعمل. يقدم Squid المحتوى المخزن مؤقتًا بغض النظر عن رأس بروتو X-forwarded الذي يشير إلى SSL أو غير ذلك.

Answer 1

OMFG.

كان لدينا هذا في .htaccess لدينا لأسباب تاريخية:

BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary

ثلاثة تخمينات ما يحدث لذاكرة التخزين المؤقت Squid بمجرد زيارة مستخدم IE 6 موقعنا. تغيير رأس إزالة. استراتيجية التخزين المؤقت مكسورة.

برغي IE. كانت إزالة هذه خطوة جيدة. كل شيء يعمل الآن.