تكوين الحبار لضمان مطابقة رأس HTTP مع المحتوى المخبوق
-
29-09-2019 - |
سؤال
لدينا إعداد سحابة مثل هذا:
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 أو غير ذلك.
المحلول
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. كانت إزالة هذه خطوة جيدة. كل شيء يعمل الآن.