एचटीटीपी कम्प्रेशन: Difference between revisions

From Vigyanwiki
No edit summary
Line 89: Line 89:
कम्प्रेशन [[सादा पाठ चुना गया|प्लेनटेक्स्ट चुना गया]] अटैक के एक रूप को निष्पादित करने की अनुमति देता है: यदि कोई अटैकर किसी भी चुनी हुई सामग्री को पृष्ठ में इंजेक्ट कर सकता है, तो वे एन्क्रिप्टेड स्ट्रीम के आकार में वृद्धि को देखकर यह जान सकते हैं कि पृष्ठ में उनकी दी गई सामग्री सम्मिलित है या नहीं। यदि वृद्धि यादृच्छिक इंजेक्शन के लिए अपेक्षा से कम है, तो इसका मतलब है कि कंप्रेसर को [[सादा पाठ चुना गया|टेक्स्ट]] में दोहराव मिला है, यानी इंजेक्शन वाली सामग्री गुप्त जानकारी को ओवरलैप करती है। [[अपराध|क्राइम]] के पीछे यही विचार है.
कम्प्रेशन [[सादा पाठ चुना गया|प्लेनटेक्स्ट चुना गया]] अटैक के एक रूप को निष्पादित करने की अनुमति देता है: यदि कोई अटैकर किसी भी चुनी हुई सामग्री को पृष्ठ में इंजेक्ट कर सकता है, तो वे एन्क्रिप्टेड स्ट्रीम के आकार में वृद्धि को देखकर यह जान सकते हैं कि पृष्ठ में उनकी दी गई सामग्री सम्मिलित है या नहीं। यदि वृद्धि यादृच्छिक इंजेक्शन के लिए अपेक्षा से कम है, तो इसका मतलब है कि कंप्रेसर को [[सादा पाठ चुना गया|टेक्स्ट]] में दोहराव मिला है, यानी इंजेक्शन वाली सामग्री गुप्त जानकारी को ओवरलैप करती है। [[अपराध|क्राइम]] के पीछे यही विचार है.


2012 में, डेटा कम्प्रेशन के उपयोग के विरुद्ध एक सामान्य हमले की घोषणा की गई, जिसे क्राइम (CRIME) कहा गया। जबकि क्राइम अटैक बड़ी संख्या में प्रोटोकॉल के खिलाफ प्रभावी ढंग से काम कर सकता है, जिसमें टीएलएस और एसपीडीवाई या एचटीटीपी जैसे एप्लिकेशन-लेयर प्रोटोकॉल सम्मिलित हैं, लेकिन केवल इन्हीं तक सीमित नहीं हैं, केवल टीएलएस और एसपीडीवाई के खिलाफ शोषण का प्रदर्शन किया गया और ब्राउज़र और सर्वर में काफी हद तक कम किया गया। एचटीटीपी कम्प्रेशन के विरुद्ध क्राइम शोषण को बिल्कुल भी कम नहीं किया गया है, भले ही क्राइम के ​​लेखकों ने चेतावनी दी है कि यह भेद्यता SPDY और TLS कम्प्रेशन से भी अधिक व्यापक हो सकती है।
2012 में, डेटा कम्प्रेशन के उपयोग के विरुद्ध एक सामान्य हमले की घोषणा की गई, जिसे क्राइम (CRIME) कहा गया। जबकि क्राइम अटैक बड़ी संख्या में प्रोटोकॉल के खिलाफ प्रभावी ढंग से काम कर सकता है, जिसमें टीएलएस और एसपीडीवाई या एचटीटीपी जैसे एप्लिकेशन-लेयर प्रोटोकॉल सम्मिलित हैं, लेकिन केवल इन्हीं तक सीमित नहीं हैं, केवल टीएलएस और एसपीडीवाई के खिलाफ शोषण का प्रदर्शन किया गया और ब्राउज़र और सर्वर में काफी हद तक कम किया गया। एचटीटीपी कम्प्रेशन के विरुद्ध क्राइम शोषण को बिल्कुल भी कम नहीं किया गया है, भले ही क्राइम के ​​लेखकों ने चेतावनी दी है कि यह भेद्यता एसपीडीवाई और टीएलएस कम्प्रेशन से भी अधिक व्यापक हो सकती है।


2013 में, एचटीटीपी कम्प्रेशन के विरुद्ध क्राइम हमले का एक नया उदाहरण, जिसे ब्रीच (BREACH) कहा गया, प्रकाशित किया गया था। एक ब्रीच अटैक टीएलएस एन्क्रिप्टेड वेब ट्रैफ़िक से लॉगिन टोकन, ईमेल पते या अन्य संवेदनशील जानकारी को कम से कम 30 सेकंड में (निकाले जाने वाले बाइट्स की संख्या के आधार पर) निकाल सकता है, बशर्ते अटैकवर पीड़ित को किसी दुर्भावनापूर्ण वेब लिंक पर जाने के लिए प्रेरित करे।<ref name=Gooin20130801>{{cite web|last=Goodin|first=Dan|title=Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages |url=https://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/|work=Ars Technica|publisher=Condé Nast|access-date=2 August 2013|date=1 August 2013}}</ref> उपयोग किए गए एन्क्रिप्शन एल्गोरिदम या सिफर की परवाह किए बिना टीएलएस और एसएसएल के सभी संस्करण ब्रीच से जोखिम में हैं।<ref>{{cite web|last=Leyden|first=John|title=Step into the BREACH: New attack developed to read encrypted web data |url=https://www.theregister.co.uk/2013/08/02/breach_crypto_attack/|work=The Register|access-date=2 August 2013|date=2 August 2013}}</ref> क्राइम (सुरक्षा शोषण) के पिछले उदाहरणों के विपरीत, जिसे टीएलएस कम्प्रेशन या एसपीडीवाई हेडर कम्प्रेशन को बंद करके सफलतापूर्वक बचाव किया जा सकता है, ब्रीच एचटीटीपी कम्प्रेशन का शोषण करता है जिसे वास्तविक रूप से बंद नहीं किया जा सकता है, क्योंकि लगभग सभी वेब सर्वर डेटा ट्रांसमिशन गति में सुधार के लिए इस पर भरोसा करते हैं। उपयोगकर्ताओं के लिएl<ref name=Gooin20130801/>
2013 में, एचटीटीपी कम्प्रेशन के विरुद्ध क्राइम हमले का एक नया उदाहरण, जिसे ब्रीच (BREACH) कहा गया, प्रकाशित किया गया था। एक ब्रीच अटैक टीएलएस एन्क्रिप्टेड वेब ट्रैफ़िक से लॉगिन टोकन, ईमेल पते या अन्य संवेदनशील जानकारी को कम से कम 30 सेकंड में (निकाले जाने वाले बाइट्स की संख्या के आधार पर) निकाल सकता है, बशर्ते अटैकवर पीड़ित को किसी दुर्भावनापूर्ण वेब लिंक पर जाने के लिए प्रेरित करे।<ref name=Gooin20130801>{{cite web|last=Goodin|first=Dan|title=Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages |url=https://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/|work=Ars Technica|publisher=Condé Nast|access-date=2 August 2013|date=1 August 2013}}</ref> उपयोग किए गए एन्क्रिप्शन एल्गोरिदम या सिफर की परवाह किए बिना टीएलएस और एसएसएल के सभी संस्करण ब्रीच से जोखिम में हैं।<ref>{{cite web|last=Leyden|first=John|title=Step into the BREACH: New attack developed to read encrypted web data |url=https://www.theregister.co.uk/2013/08/02/breach_crypto_attack/|work=The Register|access-date=2 August 2013|date=2 August 2013}}</ref> क्राइम (सुरक्षा शोषण) के पिछले उदाहरणों के विपरीत, जिसे टीएलएस कम्प्रेशन या एसपीडीवाई हेडर कम्प्रेशन को बंद करके सफलतापूर्वक बचाव किया जा सकता है, ब्रीच एचटीटीपी कम्प्रेशन का शोषण करता है जिसे वास्तविक रूप से बंद नहीं किया जा सकता है, क्योंकि लगभग सभी वेब सर्वर डेटा ट्रांसमिशन गति में सुधार के लिए इस पर भरोसा करते हैं। उपयोगकर्ताओं के लिएl<ref name=Gooin20130801/>

Revision as of 20:39, 7 August 2023

HTTP
HTTP logo.svg
Request methods
Header fields
Response status codes
Security access control methods
Security vulnerabilities

एचटीटीपी कम्प्रेशन (HTTP compression) एक क्षमता है जिसे स्थानांतरण गति और बैंडविड्थ उपयोग में सुधार के लिए वेब सर्वर और वेब क्लाइंट में बनाया जा सकता है।[1]

एचटीटीपी डेटा सर्वर से भेजे जाने से पहले डेटा कम्प्रेशन है: अनुरूप ब्राउज़र यह घोषणा करेंगे कि सही प्रारूप डाउनलोड करने से पहले सर्वर पर कौन से तरीके समर्थित हैं; जो ब्राउज़र कॉम्पलिएंट कम्प्रेशन विधि का समर्थन नहीं करते वे अनकंप्रेस्ड डेटा डाउनलोड करेंगे। सबसे आम कम्प्रेशन योजनाओं में जीज़िप (gzip) और ब्रोत्ली सम्मिलित हैं; उपलब्ध योजनाओं की पूरी सूची इंटरनेट निरुपित नंबर प्राधिकरण (आईएएनए) द्वारा रखी जाती है।[2] एचटीटीपी में दो अलग-अलग तरीकों से कम्प्रेशन किया जा सकता है। निचले स्तर पर, ट्रांसफर-एन्कोडिंग हेडर फ़ील्ड यह संकेत दे सकता है कि एचटीटीपी संदेश का पेलोड कंप्रेस्ड है। उच्च स्तर पर, एक सामग्री-एन्कोडिंग हेडर फ़ील्ड यह संकेत दे सकता है कि स्थानांतरित किया जा रहा संसाधन, वेब कैशिंग, या अन्यथा संदर्भित कंप्रेस्ड है। कंटेंट-एनकोडिंग का उपयोग करके कम्प्रेशन ट्रांसफर-एनकोडिंग की तुलना में अधिक व्यापक रूप से समर्थित है, और कुछ ब्राउज़र सर्वर में बग को ट्रिगर करने से बचने के लिए ट्रांसफर-एनकोडिंग कम्प्रेशन के लिए समर्थन का विज्ञापन नहीं करते हैं।[3]

कम्प्रेशन योजना वार्ता

बातचीत दो चरणों में की जाती है, जिसका वर्णन RFC 2616 और RFC 9110 में किया गया है:

1. वेब क्लाइंट एचटीटीपी अनुरोध में टोकन की एक सूची सम्मिलित करके विज्ञापन देता है कि वह कौन सी कम्प्रेशन योजनाओं का समर्थन करता है। सामग्री-एनकोडिंग के लिए, सूची एक्सेप्ट-एनकोडिंग नामक फ़ील्ड में है; ट्रांसफर-एन्कोडिंग के लिए, फ़ील्ड को TE कहा जाता है। <सिंटैक्सहाइलाइट लैंग= एचटीटीपी हाइलाइट=3> /एन्क्रिप्टेड-क्षेत्र एचटीटीपी/1.1 प्राप्त करें होस्ट: www.example.com स्वीकार-एन्कोडिंग: gzip, डिफ्लेट </सिंटैक्सहाइलाइट>

2. यदि सर्वर एक या अधिक कम्प्रेशन योजनाओं का समर्थन करता है, तो आउटगोइंग डेटा को दोनों पक्षों द्वारा समर्थित एक या अधिक तरीकों से कंप्रेस्ड किया जा सकता है। यदि यह स्थिति है, तो सर्वर उपयोग की गई योजनाओं के साथ एचटीटीपी प्रतिक्रिया में एक सामग्री-एनकोडिंग या ट्रांसफर-एनकोडिंग फ़ील्ड जोड़ देगा, जिसे अल्पविराम से अलग किया जाएगा।

<सिंटैक्सहाइलाइट लैंग= एचटीटीपी हाइलाइट=9> एचटीटीपी/1.1 200 ठीक है दिनांक: सोमवार, 26 जून 2016 22:38:34 जीएमटी सर्वर: अपाचे/1.3.3.7 (यूनिक्स) (रेड-हैट/लिनक्स) अंतिम-संशोधित: बुधवार, 08 जनवरी 2003 23:11:55 GMT स्वीकार-श्रेणियाँ: बाइट्स सामग्री-लंबाई: 438 कनेक्शन: बंद करें सामग्री-प्रकार: टेक्स्ट/एचटीएमएल; वर्णसेट=यूटीएफ-8 सामग्री-एन्कोडिंग: gzip </सिंटैक्सहाइलाइट>

वेब सर्वर किसी भी तरह से किसी भी कम्प्रेशन विधि का उपयोग करने के लिए बाध्य नहीं है - यह वेब सर्वर की आंतरिक सेटिंग्स पर निर्भर करता है और संबंधित वेबसाइट की आंतरिक वास्तुकला पर भी निर्भर हो सकता है।

सामग्री-एन्कोडिंग टोकन

सर्वर और क्लाइंट के लिए उपलब्ध टोकन की आधिकारिक सूची IANA द्वारा रखी जाती है,[4] और इसमें सम्मिलित हैं:

  • br - ब्रॉटली, एक कम्प्रेशन एल्गोरिदम जो विशेष रूप से एचटीटीपी सामग्री एन्कोडिंग के लिए डिज़ाइन किया गया है, में परिभाषित किया गया है RFC 7932 और सभी आधुनिक प्रमुख ब्राउज़रों में लागू किया गया।
  • कंप्रेस - UNIX कंप्रेस प्रोग्राम विधि (ऐतिहासिक; अधिकांश अनुप्रयोगों में अप्रचलित और gzip या हवा निकालना द्वारा प्रतिस्थापित)
  • डिफ्लेट - डिफ्लेट एल्गोरिथम पर आधारित कम्प्रेशन (में वर्णित है)। RFC 1951), LZ77_and_LZ78#LZ77 एल्गोरिदम और हफमैन कोडिंग का एक संयोजन, जो zlib डेटा प्रारूप के अंदर लपेटा गया है (RFC 1950);
  • exi - W3C कुशल XML इंटरचेंज
  • जीज़िप (gzip) - जीएनयू ज़िप प्रारूप (में वर्णित है)। RFC 1952). कम्प्रेशन के लिए डिफ्लेट एल्गोरिदम का उपयोग करता है, लेकिन डेटा प्रारूप और चेकसम एल्गोरिदम ''डिफ्लेट'' सामग्री-एन्कोडिंग से भिन्न होता है। मार्च 2011 तक यह पद्धति सर्वाधिक व्यापक रूप से समर्थित है।[5]
  • आइडेंटिटी (पहचान फ़ंक्शन) - किसी परिवर्तन का उपयोग नहीं किया जाता है। यह सामग्री कोडिंग के लिए डिफ़ॉल्ट मान है.
  • पैक200-जीज़िप - जावा अभिलेखागार के लिए नेटवर्क स्थानांतरण प्रारूप[6]
  • zstd - Zstandard कम्प्रेशन, में परिभाषित RFC 8478

इनके अलावा, सर्वर या क्लाइंट द्वारा कई अनौपचारिक या गैर-मानकीकृत टोकन का उपयोग किया जाता है:

  • bzip2 - मुफ़्त बीज़िप2 प्रारूप पर आधारित कम्प्रेशन, lighttpd द्वारा समर्थित[7]
  • lzma -लेम्पेल-ज़िव-मार्कोव_चेन_एल्गोरिदम - (रॉ) एलजेडएमए पर आधारित कम्प्रेशन ओपेरा 20 में उपलब्ध है, और एक संकलन-समय विकल्प के माध्यम से एलिंक्स में उपलब्ध है[8]
  • peerdist (पीयरडिस्ट)[9] - माइक्रोसॉफ्ट पीयर कंटेंट कैशिंग और पुनर्प्राप्ति
  • rsync[10] - डेल्टा _एन्कोडिंग _इन एचटीटीपी, rproxy प्रॉक्सी की एक जोड़ी द्वारा कार्यान्वित।
  • एक्सप्रेस (xpress) - माइक्रोसॉफ्ट कम्प्रेशन प्रोटोकॉल का उपयोग विंडोज 8 और बाद में विंडोज स्टोर एप्लिकेशन अपडेट के लिए किया जाता है। वैकल्पिक रूप से हफ़मैन एन्कोडिंग का उपयोग करके LZ77_and_LZ78 LZ77-आधारित कम्प्रेशन।[11]
  • xz यूटिल्स - LZMA2-आधारित सामग्री कम्प्रेशन, एक गैर-आधिकारिक फ़ायरफ़ॉक्स पैच द्वारा समर्थित;[12] और 2013-12-31 से एमजीईटी में पूरी तरह से लागू किया गया।[13]

सर्वर जो एचटीटीपी कम्प्रेशन का समर्थन करते हैं

कई सामग्री वितरण नेटवर्क अंतिम उपयोगकर्ताओं तक संसाधनों की त्वरित डिलीवरी को बेहतर बनाने के लिए एचटीटीपी कम्प्रेशन भी लागू करते हैं।

एचटीटीपी में कम्प्रेशन PHP जैसी सर्वर-साइड स्क्रिप्टिंग लैंग्वेज, या जावा (प्रोग्रामिंग लैंग्वेज) जैसी प्रोग्रामिंग लैंग्वेज की कार्यक्षमता का उपयोग करके भी प्राप्त किया जा सकता है।

एचटीटीपी कम्प्रेशन के कार्यशील कार्यान्वयन को सत्यापित करने के लिए विभिन्न ऑनलाइन उपकरण उपस्थित हैं। ये ऑनलाइन उपकरण सामान्यतः एक यूआरएल के कई वेरिएंट का अनुरोध करते हैं, प्रत्येक अलग-अलग अनुरोध हेडर (अलग-अलग स्वीकृति-एनकोडिंग सामग्री के साथ) के साथ। जब सर्वर किसी दस्तावेज़ को कंप्रेस्ड प्रारूप में लौटाता है तो एचटीटीपी कम्प्रेशन को सही ढंग से लागू माना जाता है।[17] लौटाए गए दस्तावेज़ों के आकार की तुलना करके, प्रभावी कम्प्रेशन अनुपात की गणना की जा सकती है (विभिन्न कम्प्रेशन एल्गोरिदम के बीच भी)।

एचटीटीपी कम्प्रेशन के उपयोग को रोकने में समस्याएँ

गूगल इंजीनियरों अरविंद जैन और जेसन ग्लासगो के 2009 के एक लेख में कहा गया है कि 99 से अधिक व्यक्ति-वर्ष बर्बाद हो गए हैं[18] प्रतिदिन पेज लोड समय में वृद्धि के कारण जब उपयोगकर्ताओं को कंप्रेस्ड सामग्री प्राप्त नहीं होती है। ऐसा तब होता है जब एंटी-वायरस सॉफ़्टवेयर कनेक्शन में हस्तक्षेप करके उन्हें अनकंप्रेस्ड होने के लिए बाध्य करता है, जहां प्रॉक्सी का उपयोग किया जाता है (अत्यधिक सतर्क वेब ब्राउज़र के साथ), जहां सर्वर गलत कॉन्फ़िगर किए जाते हैं, और जहां ब्राउज़र बग कम्प्रेशन का उपयोग करना बंद कर देते हैं। इंटरनेट एक्सप्लोरर 6, जो प्रॉक्सी के पीछे एचटीटीपी 1.0 (कम्प्रेशन या पाइपलाइनिंग जैसी सुविधाओं के बिना) पर चला जाता है - कॉर्पोरेट वातावरण में एक सामान्य कॉन्फ़िगरेशन - मुख्यधारा का ब्राउज़र था जो असम्पीडित एचटीटीपी पर वापस विफल होने का सबसे अधिक खतरा था।[18]

एचटीटीपी कम्प्रेशन को बड़े पैमाने पर तैनात करते समय पाई गई एक और समस्या डिफ्लेट एन्कोडिंग परिलैंग्वेज के कारण है: जबकि एचटीटीपी 1.1 डिफ्लेट एन्कोडिंग को एक zlib स्वरूपित स्ट्रीम (RFC 1950) के अंदर डिफ्लेट (RFC 1951) के साथ कंप्रेस्ड डेटा के रूप में परिभाषित करता है, Microsoft सर्वर और क्लाइंट उत्पाद ऐतिहासिक रूप से इसे एक अपरिष्कृत अपस्फीति धारा के रूप में कार्यान्वित किया,[19] इसकी तैनाती को अविश्वसनीय बनाना।[20][21] इस कारण से, अपाचे (Apache) एचटीटीपी सर्वर सहित कुछ सॉफ़्टवेयर, केवल gzip एन्कोडिंग लागू करते हैं।

सुरक्षा निहितार्थ

Main articles: क्राइम and ब्रीच

कम्प्रेशन प्लेनटेक्स्ट चुना गया अटैक के एक रूप को निष्पादित करने की अनुमति देता है: यदि कोई अटैकर किसी भी चुनी हुई सामग्री को पृष्ठ में इंजेक्ट कर सकता है, तो वे एन्क्रिप्टेड स्ट्रीम के आकार में वृद्धि को देखकर यह जान सकते हैं कि पृष्ठ में उनकी दी गई सामग्री सम्मिलित है या नहीं। यदि वृद्धि यादृच्छिक इंजेक्शन के लिए अपेक्षा से कम है, तो इसका मतलब है कि कंप्रेसर को टेक्स्ट में दोहराव मिला है, यानी इंजेक्शन वाली सामग्री गुप्त जानकारी को ओवरलैप करती है। क्राइम के पीछे यही विचार है.

2012 में, डेटा कम्प्रेशन के उपयोग के विरुद्ध एक सामान्य हमले की घोषणा की गई, जिसे क्राइम (CRIME) कहा गया। जबकि क्राइम अटैक बड़ी संख्या में प्रोटोकॉल के खिलाफ प्रभावी ढंग से काम कर सकता है, जिसमें टीएलएस और एसपीडीवाई या एचटीटीपी जैसे एप्लिकेशन-लेयर प्रोटोकॉल सम्मिलित हैं, लेकिन केवल इन्हीं तक सीमित नहीं हैं, केवल टीएलएस और एसपीडीवाई के खिलाफ शोषण का प्रदर्शन किया गया और ब्राउज़र और सर्वर में काफी हद तक कम किया गया। एचटीटीपी कम्प्रेशन के विरुद्ध क्राइम शोषण को बिल्कुल भी कम नहीं किया गया है, भले ही क्राइम के ​​लेखकों ने चेतावनी दी है कि यह भेद्यता एसपीडीवाई और टीएलएस कम्प्रेशन से भी अधिक व्यापक हो सकती है।

2013 में, एचटीटीपी कम्प्रेशन के विरुद्ध क्राइम हमले का एक नया उदाहरण, जिसे ब्रीच (BREACH) कहा गया, प्रकाशित किया गया था। एक ब्रीच अटैक टीएलएस एन्क्रिप्टेड वेब ट्रैफ़िक से लॉगिन टोकन, ईमेल पते या अन्य संवेदनशील जानकारी को कम से कम 30 सेकंड में (निकाले जाने वाले बाइट्स की संख्या के आधार पर) निकाल सकता है, बशर्ते अटैकवर पीड़ित को किसी दुर्भावनापूर्ण वेब लिंक पर जाने के लिए प्रेरित करे।[22] उपयोग किए गए एन्क्रिप्शन एल्गोरिदम या सिफर की परवाह किए बिना टीएलएस और एसएसएल के सभी संस्करण ब्रीच से जोखिम में हैं।[23] क्राइम (सुरक्षा शोषण) के पिछले उदाहरणों के विपरीत, जिसे टीएलएस कम्प्रेशन या एसपीडीवाई हेडर कम्प्रेशन को बंद करके सफलतापूर्वक बचाव किया जा सकता है, ब्रीच एचटीटीपी कम्प्रेशन का शोषण करता है जिसे वास्तविक रूप से बंद नहीं किया जा सकता है, क्योंकि लगभग सभी वेब सर्वर डेटा ट्रांसमिशन गति में सुधार के लिए इस पर भरोसा करते हैं। उपयोगकर्ताओं के लिएl[22]

2016 तक, टाइम (TIME) अटैक और हेस्ट (HEIST) अटैक अब सार्वजनिक ज्ञान हैं।[24][25][26][27]

संदर्भ

  1. ↑ "Using HTTP Compression (IIS 6.0)". Microsoft Corporation. Retrieved 9 February 2010.
  2. ↑ RFC 2616, Section 3.5: "The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens."
  3. ↑ 'RFC2616 "Transfer-Encoding: gzip, chunked" not handled properly', Chromium Issue 94730
  4. ↑ "हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल पैरामीटर्स - HTTP सामग्री कोडिंग रजिस्ट्री". IANA. Retrieved 18 April 2014.
  5. ↑ "Compression Tests: Results". Verve Studios, Co. Archived from the original on 21 March 2012. Retrieved 19 July 2012.
  6. ↑ "JSR 200: Network Transfer Format for Java Archives". The Java Community Process Program.
  7. ↑ "मॉडकंप्रेस - लाइटटीपीडी". lighty labs. Retrieved 18 April 2014.
  8. ↑ elinks LZMA decompression
  9. ↑ "[MS-PCCRTP]: Peer Content Caching and Retrieval: Hypertext Transfer Protocol (HTTP) Extensions". Microsoft. Retrieved 19 April 2014.
  10. ↑ "rproxy: Protocol Definition for HTTP rsync Encoding". rproxy.samba.org.
  11. ↑ "[MS-XCA]: Xpress Compression Algorithm". Retrieved 29 August 2015.
  12. ↑ "LZMA2 Compression - MozillaWiki". Retrieved 18 April 2014.
  13. ↑ "mget GitHub प्रोजेक्ट पेज". GitHub. Retrieved 6 January 2017.
  14. ↑ "mod_deflate - Apache HTTP Server Version 2.4 - Supported Encodings".
  15. ↑ "Extra part of Hiawatha webserver's manual".
  16. ↑ "Serving static files part of Armeria's documentation".
  17. ↑ "How does the gzip compression check work?". httptools.dev, retrieved 10 April 2022.
  18. ↑ 18.0 18.1 "वेब को तेज़ बनाने के लिए संपीड़न का उपयोग करें". Google Inc. Retrieved 22 May 2013.
  19. ↑ "deflate - Why are major web sites using gzip?". Stack Overflow. Retrieved 18 April 2014.
  20. ↑ "Compression Tests: About". Verve Studios. Archived from the original on 2 January 2015. Retrieved 18 April 2014.
  21. ↑ "Lose the wait: HTTP Compression". Zoompf Web Performance. Retrieved 18 April 2014.
  22. ↑ 22.0 22.1 Goodin, Dan (1 August 2013). "Gone in 30 seconds: New attack plucks secrets from HTTPS-protected pages". Ars Technica. Condé Nast. Retrieved 2 August 2013.
  23. ↑ Leyden, John (2 August 2013). "Step into the BREACH: New attack developed to read encrypted web data". The Register. Retrieved 2 August 2013.
  24. ↑ Sullivan, Nick (11 August 2016). "CRIME, TIME, BREACH and HEIST: A brief history of compression oracle attacks on HTTPS". Retrieved 16 August 2016.
  25. ↑ Goodin, Dan (3 August 2016). "HEIST exploit — New attack steals SSNs, e-mail addresses, and more from HTTPS pages". Retrieved 16 August 2016.
  26. ↑ Be'ery, Tal. "A Perfect Crime? TIME will tell" (PDF).
  27. ↑ Vanhoef, Mathy. "HEIST: HTTP Encrypted Information can be Stolen through TCP-windows" (PDF).


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=एचटीटीपी_कम्प्रेशन&oldid=248448’