لماذا لا يستطيع المتصفح إرسال طلب gzip؟

Question

إذا كان بإمكان خادم الويب إرسال استجابة gzip، فلماذا لا يستطيع المتصفح إرسال طلب gzip؟

Answer 1

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

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

* تحديث فبراير 2017 *لقد مرت 8 سنوات، ولكن كما لاحظ @Phil_1984_، فإن الحل الثالث المحتمل هو أن يتفاوض العميل والخادم على دعم الضغط ثم يستخدم ذلك للطلبات اللاحقة.في الواقع، تعمل أشياء مثل HSTS بهذه الطريقة مع التخزين المؤقت للعميل حيث يتوقع الخادم أن يتحدث فقط TLS ويتجاهل أي روابط غير مشفرة.تم تصميم HTTP بشكل واضح ليكون عديم الحالة ولكننا تجاوزنا ذلك في هذه المرحلة.

Answer 2

وعميل لا يمكن أن نعرف مقدما أن ملقم أن يفهم طلب مضغوط بطريقة gzip، ولكن الخادم يستطيع أن يعرف أن العميل لن يقبل واحد.

Answer 3

ويمكن، شريطة أن يمكن أن نضمن أن خادم ستقبل ذلك. قد يعني هذا باستخدام طلب OPTIONS.

وهناك الكثير من الأشياء التي متصفحات الويب يمكن أن تفعله (على سبيل المثال، خط الأنابيب) أنها لا تفعل. مطوري متصفح الويب النظر في الآثار توافق على التغيير.

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

وربما 1٪ فقط من خوادم قد تقبل طلبات المضغوطة بطريقة gzip، ولكن ربما بعض من تلك الإعلان الذي يقومون به، ولكن لا يمكن أن تقبل بشكل صحيح أنه - حتى سيمنعون من المستخدمين من تحميل الملفات إلى تلك المواقع

وتاريخيا، كان هناك الكثير من تطبيقات العميل / الخادم كسر - لفترة طويلة، ملف GZipped تم كسر الردود في متصفحات الويب الرئيسية (الحمد لله هذه هي الآن ذهب في الغالب)

.

وهكذا كنت في نهاية المطاف مع القوائم السوداء من وكلاء المستخدم أو خوادم (أو أسماء النطاقات) حيث تحولت هذه الخيارات تلقائيا، وهي سيئة.

Answer 4

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

Answer 5

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

وسيكون من السهل بما فيه الكفاية لكتابة تنفيذ GZIP في جافا سكريبت، الذي يضغط البيانات بعد إرسالها إلى الملقم. خادم يمكن أن يكون له مرشح (J2EE المدى)، الذي يعرف يتم إرسال بيانات العميل مضغوط، هذا الفلتر يخفف ضغط البيانات ومن ثم يمر البيانات إلى بريمج (أو الطبقات عمل في الدعامات) أن قراءة البيانات كما مثل العادي request.getParameter (...).

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

واندي.

Answer 6

تم تصميم HTTP بهذه الطريقة:

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

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