हाइपरटेक्स्ट परहस्त शिष्टाचार

हाइपरटेक्स्ट परहस्त शिष्टाचार
International standard	RFC 1945 HTTP/1.0; RFC 9110 HTTP Semantics; RFC 9111 HTTP Caching; RFC 9112 HTTP/1.1; RFC 9113 HTTP/2; RFC 7541 HTTP/2: HPACK Header Compression; RFC 8164 HTTP/2: Opportunistic Security for HTTP/2; RFC 8336 HTTP/2: The ORIGIN HTTP/2 Frame; RFC 8441 HTTP/2: Bootstrapping WebSockets with HTTP/2; RFC 9114 HTTP/3; RFC 9204 HTTP/3: QPACK: Field Compression;
Developed by	initially CERN; IETF, W3C
Introduced	1991; 34 years ago

हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (एचटीटीपी) वितरित, सहयोगी, हाइपरमीडिया सूचना प्रणाली के लिए इंटरनेट प्रोटोकॉल सूट मॉडल में एक एप्लीकेशन लेयर प्रोटोकॉल है।^[1] एचटीटीपी वर्ल्ड वाइड वेब के लिए डेटा संचार की नींव है, जहां हाइपरटेक्स्ट दस्तावेज़ों में अन्य संसाधनों के हाइपरलिंक्स सम्मिलित होते हैं जिन्हें उपयोगकर्ता आसानी से एक्सेस कर सकता है, उदाहरण के लिए कम्प्यूटर का माउस क्लिक या वेब ब्राउज़र में स्क्रीन टैप करके।

एचटीटीपी का विकास 1989 में सर्न में टिक बर्नर्स - ली द्वारा प्रारंभ किया गया था और क्लाइंट के व्यवहार का वर्णन करने वाले एक साधारण दस्तावेज़ में सारांशित किया गया था और पहले एचटीटीपी प्रोटोकॉल संस्करण का उपयोग करने वाले सर्वर को 0.9 नाम दिया गया था।

<रेफरी नाम = एचटीटीपी/0.9-विनिर्देश>Tim Berner-Lee (1991-01-01). "1991 में परिभाषित मूल HTTP". www.w3.org (in English). World Wide Web Consortium. Retrieved 2010-07-24.</रेफरी>

एचटीटीपी प्रोटोकॉल का वह पहला संस्करण जल्द ही एक अधिक विस्तृत संस्करण में विकसित हुआ जो कि भविष्य के संस्करण 1.0 की ओर पहला मसौदा था।^[2] यह 1997 में (संस्करण 1.1 के रूप में) विकसित हुआ और फिर इसके विनिर्देशों को 1999, 2014 और 2022 में अद्यतन किया गया। रेफरी>RFC 2068 (1997) द्वारा अप्रचलित किया गया था RFC 2616 1999 में, जिसे अप्रचलित कर दिया गया था RFC 7230 2014 में, जिसे अप्रचलित किया गया था RFC 9110 2022 में।</ref>

एचटीटीपीएस नाम का इसका सुरक्षित संस्करण 80% से अधिक वेबसाइटों द्वारा उपयोग किया जाता है।^[3]

एचटीटीपी / 2, 2015 में प्रकाशित, वायर पर एचटीटीपी के शब्दार्थ की अधिक कुशल अभिव्यक्ति प्रदान करता है। अब इसका उपयोग 41% वेबसाइटों द्वारा किया जाता है।^[4] और लगभग सभी वेब ब्राउज़रों (97% से अधिक उपयोगकर्ताओं) द्वारा समर्थित है।^[5] यह एप्लिकेशन-लेयर प्रोटोकॉल नेगोशिएशन (एएलपीएन) एक्सटेंशन का उपयोग करके परिवहन लेयर सिक्योरिटी (टीएलएस) पर प्रमुख वेब सर्वरों द्वारा भी समर्थित है।^[6] जहां टीएलएस 1.2 या नए की आवश्यकता है।^[7]^[8]

एचटीटीपी/3, एचटीटीपी/2 का उत्तराधिकारी, 2022 में प्रकाशित हुआ था।^[9] अब इसका उपयोग 25% से अधिक वेबसाइटों द्वारा किया जाता है^[10] और कई वेब ब्राउज़रों (75% से अधिक उपयोगकर्ताओं) द्वारा समर्थित है।^[11] एचटीटीपी/3 अंतर्निहित ट्रांसपोर्ट प्रोटोकॉल के लिए ट्रांसमिशन कंट्रोल प्रोटोकॉल के अतिरिक्त क्विक का उपयोग करता है। एचटीटीपी/2 की तरह, यह प्रोटोकॉल के पिछले प्रमुख संस्करणों को अप्रचलित नहीं करता है। एचटीटीपी/3 के लिए समर्थन पहले क्लाउडफ्लेयर और गूगल क्रोम में जोड़ा गया था,^[12]^[13] और फ़ायर्फ़ॉक्स में भी सक्षम है।^[14] एचटीटीपी / 3 में वास्तविक संसार के वेब पेजों के लिए कम विलंबता है, यदि सर्वर पर एचटीटीपी / 2 की तुलना में तेज़ी से लोड होता है, और एचटीटीपी / 1.1 से भी तेज़ होता है, तो कुछ स्थितियों में एचटीटीपी / 1.1 की तुलना में 3 × तेज़ (जो अभी भी सामान्यतः केवल सक्षम है) होता है।^[15]

तकनीकी अवलोकन

File:Internet1.svg

एचटीटीपी स्कीम और वर्ल्ड वाइड वेब डोमेन नाम लेबल से प्रारंभ होने वाला यूआरएल

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

वेब ब्राउजर यूजर एजेंट (यूए) का एक उदाहरण है। अन्य प्रकार के उपयोगकर्ता एजेंट में खोज प्रदाताओं (वेब क्रॉलर), वॉयस ब्राउज़र, मोबाइल एप्लिकेशन और अन्य सॉफ़्टवेयर द्वारा उपयोग किए जाने वाले इंडेक्सिंग सॉफ़्टवेयर सम्मिलित हैं जो वेब सामग्री का उपभोग या प्रदर्शित करते हैं।

एचटीटीपी को क्लाइंट और सर्वर के बीच संचार को बेहतर बनाने या सक्षम करने के लिए मध्यवर्ती नेटवर्क तत्वों को अनुमति देने के लिए डिज़ाइन किया गया है। उच्च-ट्रैफ़िक वेबसाइटें अधिकांश वेब कैश सर्वर से लाभान्वित होती हैं जो प्रतिक्रिया समय को बेहतर बनाने के लिए अपस्ट्रीम सर्वर की ओर से सामग्री वितरित करती हैं। वेब ब्राउज़र पहले से एक्सेस किए गए वेब संसाधनों को कैश करते हैं और नेटवर्क ट्रैफ़िक को कम करने के लिए, जब भी संभव हो, तब उनका पुन: उपयोग करते हैं। निजी नेटवर्क सीमाओं पर एचटीटीपी प्रॉक्सी सर्वर बाहरी सर्वर के साथ संदेशों को रिले करके वैश्विक रूप से निष्क्रिय पते के बिना ग्राहकों के लिए संचार की सुविधा प्रदान कर सकते हैं।

इंटरमीडिएट एचटीटीपी नोड्स (प्रॉक्सी सर्वर, वेब कैश आदि) को उनके कार्यों को पूरा करने की अनुमति देने के लिए, एचटीटीपी हेडर फ़ील्ड की सूची (एचटीटीपी अनुरोधों/प्रतिक्रियाओं में पाई जाती है) को हॉप-बाय-हॉप प्रबंधित किया जाता है जबकि अन्य एचटीटीपी शीर्षलेख एंड-टू-एंड सिद्धांत प्रबंधित हैं (केवल स्रोत क्लाइंट और लक्ष्य वेब सर्वर द्वारा प्रबंधित)।

एचटीटीपी एक एप्लिकेशन लेयर प्रोटोकॉल है जिसे इंटरनेट प्रोटोकॉल सूट के संरचना के अन्दर डिज़ाइन किया गया है। इसकी परिभाषा एक अंतर्निहित और विश्वसनीय ट्रांसपोर्ट लेयर प्रोटोकॉल मानती है,^[16] इस प्रकार ट्रांसमिशन कंट्रोल प्रोटोकॉल (टीसीपी) का सामान्यतः उपयोग किया जाता है। चूँकि, एचटीटीपी को उपयोगकर्ता डेटाग्राम प्रोटोकॉल उपयोगकर्ता (यूडीपी) जैसे अविश्वसनीय प्रोटोकॉल का उपयोग करने के लिए अनुकूलित किया जा सकता है, उदाहरण के लिए एचटीटीपीयू और सरल सेवा डिस्कवरी प्रोटोकॉल (एसएसडीपी) में।

यूनिफॉर्म रिसोर्स पहचानकर्ता (यूआरआई'एस) योजनाओं एचटीटीपी और एचटीटीपीएस का उपयोग करके, यूनिफ़ॉर्म रिसोर्स लोकेटरस (यूआरएल) द्वारा वेब संसाधनों की पहचान की जाती है और नेटवर्क पर स्थित किया जाता है। जैसा कि परिभाषित किया गया है RFC 3986, URI को एचटीएमएल दस्तावेज़ों में हाइपरलिंक्स के रूप में एन्कोड किया गया है, जिससे आपस में जुड़े हाइपरटेक्स्ट दस्तावेज़ बन सकें।

एचटीटीपी/1.0 में प्रत्येक संसाधन अनुरोध के लिए एक ही सर्वर के लिए एक अलग कनेक्शन-उन्मुख संचार किया जाता है।^[17]

एचटीटीपी/1.1 में इसके अतिरिक्त एक टीसीपी कनेक्शन का पुन: उपयोग कई संसाधन अनुरोध (अर्थात् एचटीएमएल पेज, फ्रेम, इमेज, क्लाइंट-साइड स्क्रिप्टिंग, व्यापक शैली पत्रक आदि) करने के लिए किया जा सकता है।^[18]^[19]

एचटीटीपी/1.1 संचार इसलिए कम विलंबता (इंजीनियरिंग) का अनुभव करते हैं क्योंकि टीसीपी कनेक्शन की स्थापना विशेष रूप से उच्च यातायात स्थितियों के अनुसार अधिक ओवरहेड प्रस्तुत करती है।^[20]

एचटीटीपी/2 पिछले एचटीटीपी/1.1 का एक संशोधन है जिससे समान क्लाइंट-सर्वर मॉडल और समान प्रोटोकॉल विधियों को बनाए रखा जा सके लेकिन इन अंतरों के क्रम में:

टेक्स्ट के अतिरिक्त मेटाडेटा (एचटीटीपी हेडर) के एक संकुचित बाइनरी प्रतिनिधित्व का उपयोग करने के लिए, जिससे हेडर को बहुत कम जगह की आवश्यकता हो;
2 से 8 टीसीपी/आईपी कनेक्शन के अतिरिक्त प्रत्येक एक्सेस किए गए सर्वर डोमेन के लिए एक टीसीपी/इंटरनेट प्रोटोकॉल (सामान्यतः कूटलेखन) कनेक्शन का उपयोग करने के लिए;
प्रति टीसीपी / आईपी कनेक्शन में एक या एक से अधिक द्विदिश धाराओं का उपयोग करने के लिए जिसमें एचओएलबी (हेड-ऑफ-लाइन ब्लॉकिंग) की समस्या को समाधान करने के लिए एचटीटीपी अनुरोधों और प्रतिक्रियाओं को तोड़ दिया जाता है और छोटे पैकेटों में प्रेषित किया जाता है। ^{[note 1]}
जब भी नया डेटा उपलब्ध हो, सर्वर एप्लिकेशन को ग्राहकों को डेटा भेजने की अनुमति देने के लिए एक पुश क्षमता जोड़ने के लिए (ग्राहकों को मतदान (कंप्यूटर विज्ञान) विधियों का उपयोग करके सर्वर से समय-समय पर नए डेटा का अनुरोध करने के लिए विवश किए बिना)।^[21]

एचटीटीपी/2 संचार इसलिए बहुत कम विलंबता का अनुभव करते हैं और, अधिकांश स्थितियों में, एचटीटीपी/1.1 संचार से भी अधिक गति का अनुभव करते हैं।

एचटीटीपी/3 टीसीपी/आईपी कनेक्शन के अतिरिक्त क्विक + यूडीपी ट्रांसपोर्ट प्रोटोकॉल का उपयोग करने के लिए पिछले एचटीटीपी/2 का एक संशोधन है, संचार की औसत गति में थोड़ा सुधार करने और टीसीपी/आईपी कनेक्शन की सामयिक (बहुत दुर्लभ) समस्या से बचने के लिए टीसीपी भीड़ नियंत्रण जो अपनी सभी धाराओं के डेटा प्रवाह को अस्थायी रूप से ब्लॉक या धीमा कर सकता है ('हेड ऑफ लाइन ब्लॉकिंग का दूसरा रूप)।

इतिहास

टिक बैरनर्स - ली

हाइपरटेक्स्ट शब्द टेड नेल्सन द्वारा 1965 में ज़ानाडू प्रोजेक्ट में गढ़ा गया था, जो वन्नेवर बुश के 1930 के दशक के माइक्रोफिल्म-आधारित सूचना पुनर्प्राप्ति और प्रबंधन मेमेक्स प्रणाली से प्रेरित था, जिसे उनके 1945 के निबंध ऐज़ वी मे थिंक में वर्णित किया गया था। सर्न में टिम बर्नर्स-ली और उनकी टीम को एचटीटीपी और वेब सर्वर के लिए संबंधित तकनीक और वेब ब्राउज़र नामक क्लाइंट प्रयोक्ता इंटरफ़ेस के साथ मूल एचटीटीपी का आविष्कार करने का श्रेय दिया जाता है। बर्नर्स-ली ने अपने अन्य विचार को अपनाने में सहायता करने के लिए एचटीटीपी को डिज़ाइन किया: वर्ल्डवाइडवेब प्रोजेक्ट, जिसे पहली बार 1989 में प्रस्तावित किया गया था, जिसे अब वर्ल्ड वाइड वेब के रूप में जाना जाता है।

सीईआरएन एचटीटीपीडी 1990 में लाइव हुआ।^[22]^[23] उपयोग किए गए प्रोटोकॉल में केवल एक विधि थी, अर्थात् जीईटी, जो एक सर्वर से एक पृष्ठ का अनुरोध करेगी।^[24] सर्वर से प्रतिक्रिया हमेशा एक एचटीटी पी पृष्ठ होती थी।^[25]

एचटीटीपी मील के पत्थर संस्करणों का सारांश

संस्करण	साल प्रस्तुत किया	वर्तमान स्थिति
एचटीटीपी/0.9	1991	Obsolete
एचटीटीपी/1.0	1996	Obsolete
एचटीटीपी/1.1	1997	Standard
एचटीटीपी/2	2015	Standard
एचटीटीपी/3	2022	Standard

एचटीटीपी/0.9

1991 में, एचटीटीपी का पहला प्रलेखित आधिकारिक संस्करण एक सादे दस्तावेज़ के रूप में लिखा गया था, जो 700 शब्दों से कम लंबा था, और इस संस्करण को एचटीटीपी/0.9 नाम दिया गया था। एचटीटीपी/0.9 केवल जीईटी विधि का समर्थन करता है, और क्लाइंट को सर्वर से केवल एचटीएमएल दस्तावेज़ प्राप्त करने की अनुमति देता है, लेकिन किसी अन्य फ़ाइल स्वरूपों या सूचना अपलोड का समर्थन नहीं करता है।^[25]

एचटीटीपी/1.0-ड्राफ्ट

1992 के बाद से, इसके अगले पूर्ण संस्करण के लिए मूल प्रोटोकॉल के विकास को निर्दिष्ट करने के लिए एक नया दस्तावेज़ लिखा गया था। यह 0.9 संस्करण की सरल अनुरोध विधि और क्लाइंट एचटीटीपी संस्करण को सम्मिलित करने वाले पूर्ण जीईटी अनुरोध दोनों का समर्थन करता है। यह कई अनौपचारिक एचटीटीपी/1.0 ड्राफ्ट में से पहला था जो एचटीटीपी/1.0 पर अंतिम कार्य से पहले था।^[2]

W3C एचटीटीपी वर्किंग ग्रुप

यह तय करने के बाद कि एचटीटीपी प्रोटोकॉल की नई विशेषताओं की आवश्यकता थी और उन्हें टिप्पणियों के लिए आधिकारिक अनुरोध के रूप में पूरी तरह से प्रलेखित किया जाना था, 1995 के प्रारंभ में मानकीकरण के उद्देश्य से एचटीटीपी वर्किंग ग्रुप (एचटीटीपी WG, डेव रैगेट के नेतृत्व में) का गठन किया गया था और विस्तारित संचालन, विस्तारित बातचीत, समृद्ध मेटा-सूचना के साथ प्रोटोकॉल का विस्तार करें, एक सुरक्षा प्रोटोकॉल से जुड़ा हुआ है जो अतिरिक्त विधियों और एचटीटीपी हेडर फ़ील्ड की सूची जोड़कर अधिक कुशल हो गया है।^[26]^[27]

एचटीटीपी WG ने 1995 के अन्दर एचटीटीपी/1.0 और एचटीटीपी/1.1 के रूप में प्रोटोकॉल के नए संस्करणों को संशोधित और प्रकाशित करने की योजना बनाई, लेकिन, कई संशोधनों के कारण, यह समयरेखा एक वर्ष से अधिक चली।^[28]

एचटीटीपी डब्ल्यूजी ने एचटीटीपी-एनजी (एचटीटीपी नेक्स्ट जेनरेशन) नामक एचटीटीपी के भविष्य के संस्करण को निर्दिष्ट करने की भी योजना बनाई है, जो प्रदर्शन, कम विलंबता प्रतिक्रियाओं आदि से संबंधित पिछले संस्करणों की सभी शेष समस्याओं को समाधान कर देगा, लेकिन यह काम केवल प्रारंभ हुआ कुछ साल बाद और यह कभी पूरा नहीं हुआ।

एचटीटीपी/1.0

मई 1996 में, RFC 1945 पूर्व-मानक एचटीटीपी/1.0-ड्राफ्ट के रूप में पिछले 4 वर्षों में जो उपयोग किया गया था, उसके अंतिम एचटीटीपी/1.0 संशोधन के रूप में प्रकाशित किया गया था जो पहले से ही कई वेब ब्राउज़र और वेब सर्वर द्वारा उपयोग किया गया था।; 1996 के प्रारंभ में डेवलपर्स ने आगामी एचटीटीपी/1.1 विनिर्देशों के ड्राफ्ट का उपयोग करके अपने उत्पादों में एचटीटीपी/1.0 प्रोटोकॉल के अनौपचारिक विस्तार (अर्थात् कनेक्शन को जीवित रखना, आदि) को सम्मिलित करना प्रारंभ कर दिया।^[29]एचटीटीपी/1.1; 1996 की प्रारंभ से, प्रमुख वेब ब्राउज़र और वेब सर्वर डेवलपर्स ने भी पूर्व-मानक एचटीटीपी/1.1 ड्राफ्ट विनिर्देशों द्वारा निर्दिष्ट नई सुविधाओं को प्रायुक्त करना प्रारंभ कर दिया। ब्राउज़रों और सर्वरों के नए संस्करणों को एंड-यूज़र अपनाने की गति तेज़ थी। मार्च 1996 में, एक वेब होस्टिंग कंपनी ने बताया कि इंटरनेट पर उपयोग में आने वाले 40% से अधिक ब्राउज़रों ने वर्चुअल होस्टिंग को सक्षम करने के लिए नए एचटीटीपी/1.1 हेडर होस्ट का उपयोग किया। उसी वेब होस्टिंग कंपनी ने बताया कि जून 1996 तक, उनके सर्वर तक पहुँचने वाले सभी ब्राउज़रों में से 65% पूर्व-मानक एचटीटीपी/1.1 अनुरूप थे।^[30]; जनवरी 1997 में, RFC 2068 आधिकारिक तौर पर एचटीटीपी/1.1 विनिर्देशों के रूप में जारी किया गया था।; जून 1999 में, RFC 2616 पिछले (अप्रचलित) एचटीटीपी/1.1 विनिर्देशों के आधार पर सभी सुधारों और अद्यतनों को सम्मिलित करने के लिए जारी किया गया था।
डब्ल्यू3सी एचटीटीपी-एनजी वर्किंग ग्रुप: पिछले एचटीटीपी वर्किंग ग्रुप की 1995 की पुरानी योजना को फिर से प्रारंभ करते हुए, 1997 में एचटीटीपी-एनजी (एचटीटीपी न्यू जनरेशन) नामक एक नया एचटीटीपी प्रोटोकॉल विकसित करने के लिए एक एचटीटीपी-एनजी वर्किंग ग्रुप बनाया गया था। एक एकल टीसीपी/आईपी कनेक्शन के अंदर एचटीटीपी लेनदेन के बहुसंकेतन का उपयोग करने के लिए नए प्रोटोकॉल के लिए कुछ प्रस्ताव/ड्राफ्ट तैयार किए गए थे, लेकिन 1999 में, समूह ने आईईटीएफ को तकनीकी समस्याओं को पास करते हुए अपनी गतिविधि बंद कर दी।^[31]

आईईटीएफ एचटीटीपी वर्किंग ग्रुप फिर से प्रारंभ हुआ

2007 में, IETF एचटीटीपी Working Group (एचटीटीपी WG bis या एचटीटीपीbis) को पहले पिछले एचटीटीपी/1.1 विनिर्देशों को संशोधित करने और स्पष्ट करने के लिए और दूसरा भविष्य के एचटीटीपी/2 विनिर्देशों को लिखने और परिष्कृत करने के लिए फिर से प्रारंभ किया गया था ( नाम httpbis)।^[32]^[33]
स्पीडी: गूगल द्वारा विकसित एक अनौपचारिक एचटीटीपी प्रोटोकॉल: 2009 में, गूगल, एक निजी कंपनी, ने घोषणा की कि उसने स्पीडी नामक एक नए एचटीटीपी बाइनरी प्रोटोकॉल का विकास और परीक्षण किया है। निहित उद्देश्य वेब ट्रैफ़िक को बहुत तेज़ करना था (विशेष रूप से भविष्य के वेब ब्राउज़र और उसके सर्वर के बीच)।; एसपीडीवाई वास्तव में कई परीक्षणों में एचटीटीपी/1.1 की तुलना में बहुत तेज था और इसलिए इसे क्रोमियम (वेब ब्राउज़र) और फिर अन्य प्रमुख वेब ब्राउज़रों द्वारा जल्दी से अपनाया गया था।^[34]; एक ही टीसीपी/आईपी कनेक्शन पर एचटीटीपी स्ट्रीम को मल्टीप्लेक्स करने के बारे में कुछ विचार डब्ल्यू3सी एचटीटीपी-एनजी वर्किंग ग्रुप के काम सहित विभिन्न स्रोतों से लिए गए थे।

एचटीटीपी/2

जनवरी-मार्च 2012 में, HTTP वर्किंग ग्रुप (HTTPbis) ने एक नए HTTP/2 प्रोटोकॉल (HTTP/1.1 विनिर्देशों के संशोधन को पूरा करते समय) पर ध्यान केंद्रित करने की आवश्यकता की घोषणा की, शायद SPDY के लिए विचारों और किए गए कार्यों को ध्यान में रखते हुए।

रेफरी नाम = HTTPbis-rechartering-prop >"httpbis को रिचार्ज करना" (in English). IETF; HTTP WG. 2012-01-24. Retrieved 2021-10-19.</रेफरी>^[35]

एचटीटीपी का एक नया संस्करण विकसित करने के लिए क्या करना है, इसके बारे में कुछ महीनों के बाद, इसे स्पीडी से प्राप्त करने का निर्णय लिया गया।^[36]

मई 2015 में, HTTP/2 को इस रूप में प्रकाशित किया गया था RFC 7540 और पहले से ही एसपीडीवाई का समर्थन करने वाले सभी वेब ब्राउज़रों द्वारा तेजी से अपनाया गया और वेब सर्वरों द्वारा धीरे-धीरे अपनाया गया।

2014 HTTP/1.1 के लिए अद्यतन

जून 2014 में, HTTP वर्किंग ग्रुप ने एक अद्यतन छह-भाग HTTP / 1.1 विनिर्देश अप्रचलित जारी किया RFC 2616:

RFC 7230, HTTP/1.1: संदेश सिंटैक्स और रूटिंग
RFC 7231, एचटीटीपी/1.1: शब्दार्थ और सामग्री
RFC 7232, HTTP/1.1: सशर्त अनुरोध
RFC 7233, HTTP/1.1: रेंज अनुरोध
RFC 7234, HTTP/1.1: कैशिंग
RFC 7235, एचटीटीपी/1.1: प्रमाणीकरण

HTTP/0.9 मूल्यह्रास

में RFC 7230 परिशिष्ट-A, HTTP/0.9 को HTTP/1.1 संस्करण (और उच्चतर) का समर्थन करने वाले सर्वरों के लिए बहिष्कृत कर दिया गया था:<ref name="rfc7230-Appendix-A">"Appendix-A: HTTP Version History". RFC 7230, HTTP/1.1: Message Syntax and Routing. p. 78. sec. A. doi:10.17487/RFC7230. RFC 7230.</ref>

चूंकि एचटीटीपी / 0.9 अनुरोध में हेडर फ़ील्ड का समर्थन नहीं करता है, इसके लिए नाम-आधारित वर्चुअल होस्ट (होस्ट हेडर फ़ील्ड के निरीक्षण द्वारा संसाधनों का चयन) का समर्थन करने के लिए कोई तंत्र नहीं है। 'कोई भी सर्वर जो नाम-आधारित वर्चुअल होस्ट लागू करता है, उसे एचटीटीपी/0.9 के लिए समर्थन अक्षम करना चाहिए। अधिकांश अनुरोध जो एचटीटीपी/0.9 प्रतीत होते हैं, वास्तव में, क्लाइंट द्वारा अनुरोध-लक्ष्य को ठीक से एन्कोड करने में विफल होने के कारण बुरी तरह से निर्मित एचटीटीपी/1.x अनुरोध हैं।

2016 के बाद से कई उत्पाद प्रबंधकों और उपयोगकर्ता एजेंटों (ब्राउज़र, आदि) और वेब सर्वर के डेवलपर्स ने मुख्य रूप से निम्नलिखित कारणों से एचटीटीपी/0.9 प्रोटोकॉल के समर्थन को धीरे-धीरे कम करने और खारिज करने की योजना बनाना प्रारंभ कर दिया है:^[37]

यह इतना सरल है कि एक RFC दस्तावेज़ कभी नहीं लिखा गया था (केवल मूल दस्तावेज़ है);^[25]
इसमें कोई एचटीटीपी हेडर नहीं है और कई अन्य विशेषताओं का अभाव है जो आजकल न्यूनतम सुरक्षा कारणों से आवश्यक हैं;
यह 1999..2000 (HTTP/1.0 और HTTP/1.1 के कारण) से व्यापक नहीं हुआ है और आमतौर पर केवल कुछ बहुत पुराने नेटवर्क हार्डवेयर, यानी राउटर (कंप्यूटिंग), आदि द्वारा उपयोग किया जाता है।

^{[note 2]}

एचटीटीपी/3

2020 में, पहला ड्राफ्ट HTTP/3 प्रकाशित किया गया और प्रमुख वेब ब्राउज़र और वेब सर्वर ने इसे अपनाना शुरू कर दिया।

6 जून 2022 को आईईटीएफ ने एचटीटीपी/3 को मानकीकृत किया RFC 9114.^[38]

2022 में अपडेट और रीफैक्टरिंग

जून 2022 में, आरएफसी का एक बैच प्रकाशित किया गया था, जिसमें पिछले कई दस्तावेज़ों को हटा दिया गया था और कुछ छोटे बदलावों को प्रस्तुत किया गया था और एक अलग दस्तावेज़ में एचटीटीपी सिमेंटिक विवरण की रीफैक्टरिंग की गई थी।

RFC 9110, एचटीटीपी शब्दार्थ
RFC 9111, एचटीटीपी कैशिंग
RFC 9112, एचटीटीपी/1.1
RFC 9113, एचटीटीपी/2
RFC 9114, एचटीटीपी/3 (उपरोक्त अनुभाग भी देखें)
RFC 9204, क्यूपैक: एचटीटीपी/3 के लिए फील्ड कंप्रेशन
RFC 9218, एचटीटीपी के लिए एक्स्टेंसिबल प्राथमिकता योजना

एचटीटीपी डेटा एक्सचेंज

एचटीटीपी एक स्टेटलेस प्रोटोकॉल एप्लिकेशन-लेवल प्रोटोकॉल है और इसे क्लाइंट और सर्वर के बीच डेटा के आदान-प्रदान के लिए एक विश्वसनीय नेटवर्क ट्रांसपोर्ट कनेक्शन की आवश्यकता होती है।^[16] एचटीटीपी कार्यान्वयन में, ट्रांसमिशन कंट्रोल प्रोटोकॉल | टीसीपी/आईपी कनेक्शन का उपयोग प्रसिद्ध टीसीपी और यूडीपी पोर्टस का उपयोग करके किया जाता है (सामान्यतः टीसीपी पोर्ट यदि कनेक्शन अनएन्क्रिप्टेड है या पोर्ट 443 यदि कनेक्शन एन्क्रिप्ट किया गया है, तो टीसीपी और यूडीपी पोर्ट नंबरों की सूची भी देखें)।^[39]^[40] एचटीटीपी/2 में, एक टीसीपी/आईपी कनेक्शन और कई प्रोटोकॉल चैनल का उपयोग किया जाता है। एचटीटीपी/3 में, यूडीपी पर एप्लिकेशन ट्रांसपोर्ट प्रोटोकॉल क्विक का उपयोग किया जाता है।

कनेक्शन के माध्यम से अनुरोध और प्रतिक्रिया संदेश

अनुरोध-प्रतिक्रिया | अनुरोध-प्रतिक्रिया संदेशों के अनुक्रम के माध्यम से डेटा का आदान-प्रदान किया जाता है, जो एक सत्र लेयर परिवहन कनेक्शन द्वारा आदान-प्रदान किया जाता है।^[16]एक एचटीटीपी क्लाइंट प्रारंभ में एक कनेक्शन (वास्तविक या वर्चुअल) स्थापित करने वाले सर्वर से कनेक्ट करने का प्रयास करता है। उस पोर्ट पर सुनने वाला एचटीटीपी(एस) सर्वर कनेक्शन स्वीकार करता है और फिर क्लाइंट के अनुरोध संदेश की प्रतीक्षा करता है। क्लाइंट सर्वर को अपना अनुरोध भेजता है। अनुरोध प्राप्त होने पर, सर्वर एक एचटीटीपी प्रतिक्रिया संदेश वापस भेजता है (यदि आवश्यक हो तो हेडर प्लस बॉडी)। इस संदेश का मुख्य भाग सामान्यतः अनुरोधित संसाधन है, चूंकि एक त्रुटि संदेश या अन्य जानकारी भी लौटाई जा सकती है। किसी भी समय (कई कारणों से) क्लाइंट या सर्वर कनेक्शन बंद कर सकता है। सर्वर या क्लाइंट को भेजे गए अंतिम अनुरोध/प्रतिक्रिया संदेश में एक या अधिक एचटीटीपी शीर्षलेखों का उपयोग करके सामान्यतः एक कनेक्शन बंद करना अग्रिम रूप से विज्ञापित किया जाता है।^[18]

लगातार कनेक्शन

एचटीटीपी/0.9 में, सर्वर प्रतिक्रिया भेजे जाने के बाद टीसीपी/आईपी कनेक्शन हमेशा बंद रहता है, इसलिए यह कभी भी स्थायी नहीं होता है।

एचटीटीपी/1.0 में, जैसा कि [rfc:1945 आरएफसी 1945] में कहा गया है, प्रतिक्रिया भेजे जाने के बाद टीसीपी/आईपी कनेक्शन को हमेशा सर्वर द्वारा बंद कर दिया जाना चाहिए। ^{[note 3]}

एचटीटीपी/1.1 में एक कीप-अलाइव-मैकेनिज्म को आधिकारिक तौर पर प्रस्तुत किया गया था जिससे एक से अधिक अनुरोध/प्रतिक्रिया के लिए एक कनेक्शन का पुन: उपयोग किया जा सके। इस तरह के लगातार कनेक्शन अनुरोध विलंबता को स्पष्ट रूप से कम कर देते हैं क्योंकि क्लाइंट को पहला अनुरोध भेजे जाने के बाद टीसीपी 3-वे-हैंडशेक कनेक्शन पर फिर से बातचीत करने की आवश्यकता नहीं होती है। एक और सकारात्मक पक्ष प्रभाव यह है कि, सामान्य तौर पर टीसीपी के धीमे-प्रारंभ-तंत्र के कारण कनेक्शन समय के साथ तेज हो जाता है।

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

एचटीटीपी/2 ने एक ही टीसीपी/आईपी कनेक्शन के माध्यम से कई समवर्ती अनुरोधों/प्रतिक्रियाओं को मल्टीप्लेक्स करके लगातार कनेक्शन के उपयोग को बढ़ाया।

एचटीटीपी/3 टीसीपी/आईपी कनेक्शन का उपयोग नहीं करता है लेकिन क्विक + यूडीपी (यह भी देखें: तकनीकी अवलोकन)।

सामग्री पुनर्प्राप्ति अनुकूलन

एचटीटीपी/0.9

एक अनुरोधित संसाधन हमेशा पूरी तरह से भेजा गया था।

एचटीटीपी/1.0

सशर्त जीईटी अनुरोधों को अनुमति देने के लिए क्लाइंट द्वारा कैश किए गए संसाधनों को प्रबंधित करने के लिए एचटीटीपी / 1.0 हेडर जोड़े गए; व्यवहार में एक सर्वर को अनुरोधित संसाधन की पूरी सामग्री को केवल तभी वापस करना होता है जब उसका अंतिम संशोधित समय क्लाइंट द्वारा ज्ञात नहीं होता है या यदि यह जीईटी अनुरोध के अंतिम पूर्ण प्रतिक्रिया के बाद बदल जाता है। इन शीर्षलेखों में से एक, सामग्री-एन्कोडिंग को यह निर्दिष्ट करने के लिए जोड़ा गया था कि संसाधन की लौटाई गई सामग्री एचटीटीपी संपीड़न थी या नहीं।

यदि किसी संसाधन की सामग्री की कुल लंबाई पहले से ज्ञात नहीं थी (अर्थात क्योंकि यह गतिशील रूप से उत्पन्न हुई थी, आदि) तो हेडर "Content-Length: number" एचटीटीपी हेडर में उपस्थित नहीं था और क्लाइंट ने माना कि जब सर्वर ने कनेक्शन बंद कर दिया, तो सामग्री पूरी तरह से भेज दी गई थी। यह तंत्र एक संसाधन हस्तांतरण के बीच सफलतापूर्वक पूर्ण और एक बाधित (एक सर्वर / नेटवर्क त्रुटि या कुछ और के कारण) के बीच अंतर नहीं कर सका।

एचटीटीपी/1.1

एचटीटीपी/1.1 प्रस्तुत किया गया:

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

* बाइट सर्विंग, जहां एक ग्राहक संसाधन के केवल एक या अधिक भाग (बाइट्स की श्रेणियां) का अनुरोध कर सकता है (अर्थात् पहला भाग, बीच में एक हिस्सा या पूरी सामग्री के अंत में, आदि) और सर्वर सामान्यतः केवल अनुरोधित भाग भेजता है (एस)। यह एक बाधित डाउनलोड (जब फ़ाइल वास्तव में बड़ी है) को फिर से प्रारंभ करने के लिए उपयोगी है, जब समय, बैंडविड्थ और प्रणाली संसाधनों आदि को खाली करने के लिए किसी सामग्री का केवल एक हिस्सा एक ब्राउज़र द्वारा पहले से ही दिखाई देने वाले हिस्से में दिखाया जाना है या गतिशील रूप से जोड़ा जाना है (अर्थात किसी वेब पेज की केवल पहली या निम्नलिखित टिप्पणी)।

एचटीटीपी/2, एचटीटीपी/3

एचटीटीपी/2 और एचटीटीपी/3 दोनों में एचटीटीपी/1.1 की उपरोक्त विशेषताएं रखी गई हैं।

एचटीटीपी प्रमाणीकरण

एचटीटीपी कई प्रमाणीकरण योजनाएँ प्रदान करता है जैसे कि मूलभूत पहुँच प्रमाणीकरण और डाइजेस्ट एक्सेस प्रमाणीकरण जो एक चुनौती-प्रतिक्रिया तंत्र के माध्यम से संचालित होता है जिससे सर्वर अनुरोधित सामग्री की सेवा करने से पहले एक चुनौती की पहचान करता है और उसे जारी करता है।

एचटीटीपी चुनौती-प्रतिक्रिया प्रमाणीकरण योजनाओं के एक विस्तृत सेट के माध्यम से अभिगम नियंत्रण और प्रमाणीकरण के लिए एक सामान्य संरचना प्रदान करता है, जिसका उपयोग सर्वर द्वारा क्लाइंट अनुरोध को चुनौती देने के लिए और क्लाइंट द्वारा प्रमाणीकरण जानकारी प्रदान करने के लिए किया जा सकता है।^[1]

ऊपर वर्णित प्रमाणीकरण तंत्र एचटीटीपी प्रोटोकॉल से संबंधित हैं और क्लाइंट और सर्वर एचटीटीपी सॉफ़्टवेयर द्वारा प्रबंधित किए जाते हैं (यदि क्लाइंट को एक या अधिक वेब संसाधनों तक क्लाइंट पहुंच की अनुमति देने से पहले प्रमाणीकरण की आवश्यकता के लिए कॉन्फ़िगर किया गया है), और एचटीटीपी एप्लिकेशन सत्र का उपयोग करने वाले वेब एप्लिकेशन द्वारा नहीं किया गया था।

प्रमाणीकरण क्षेत्र

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

एचटीटीपी आवेदन सत्र

एचटीटीपी एक स्टेटलेस प्रोटोकॉल है। एक स्टेटलेस प्रोटोकॉल के लिए वेब सर्वर को एकाधिक अनुरोधों की अवधि के लिए प्रत्येक उपयोगकर्ता के बारे में जानकारी या स्थिति बनाए रखने की आवश्यकता नहीं होती है।

कुछ वेब एप्लिकेशन को उपयोगकर्ता सत्रों को प्रबंधित करने की आवश्यकता होती है, इसलिए वे उदाहरण के लिए एचटीटीपी कुकीज़ का उपयोग करके राज्यों या सत्र (कंप्यूटर विज्ञान) को प्रायुक्त करते हैं^[41] या छिपे हुए चर (कंप्यूटर विज्ञान) प्रपत्र (वेब) के अन्दर हैं।

एप्लिकेशन उपयोगकर्ता सत्र प्रारंभ करने के लिए, वेब एप्लिकेशन लॉग इन करें के माध्यम से एक इंटरैक्टिव प्रमाणीकरण किया जाना चाहिए। उपयोगकर्ता सत्र को रोकने के लिए उपयोगकर्ता द्वारा लॉग आउट ऑपरेशन का अनुरोध किया जाना चाहिए। इस प्रकार के संचालन #एचटीटीपी प्रमाणीकरण का उपयोग नहीं करते हैं किन्तु एक कस्टम प्रबंधित वेब एप्लीकेशन प्रमाणीकरण का उपयोग करते हैं।

एचटीटीपी/1.1 अनुरोध संदेश

अनुरोध संदेश क्लाइंट द्वारा लक्षित सर्वर को भेजे जाते हैं।^{[note 4]}

अनुरोध सिंटैक्स

क्लाइंट सर्वर को अनुरोध संदेश भेजता है, जिसमें निम्न सम्मिलित हैं:^[42]

एक अनुरोध पंक्ति, जिसमें केस-संवेदी अनुरोध विधि, एक स्थान (विराम चिह्न), अनुरोधित यूआरएल, अन्य स्थान, प्रोटोकॉल संस्करण, एक कैरिज रिटर्न और एक रेखा भरण सम्मिलित है, उदाहरण के लिए:

GET /images/logo.png HTTP/1.1

शून्य या अधिक एचटीटीपी अनुरोध शीर्षलेख फ़ील्ड (एचटीटीपी/1.1 के स्थिति में कम से कम 1 या अधिक शीर्षलेख), प्रत्येक में केस-असंवेदनशील फ़ील्ड नाम, एक कोलन, वैकल्पिक अग्रणी व्हाइटस्पेस (कंप्यूटर विज्ञान), फ़ील्ड मान, एक वैकल्पिक ट्रेलिंग व्हॉट्सएप और एक कैरिज रिटर्न और एक लाइन फीड के साथ समाप्त होता है, उदा .:

Host: www.example.com
Accept-Language: en

एक खाली लाइन, जिसमें कैरिज रिटर्न और लाइन फीड सम्मिलित है;
एक वैकल्पिक एचटीटीपी संदेश निकाय।

एचटीटीपी/1.1 प्रोटोकॉल में, सभी हेडर फ़ील्ड को छोड़कर Host: hostname वैकल्पिक हैं।

RFC 1945 में एचटीटीपी / 1.0 विनिर्देश से पहले एचटीटीपी क्लाइंट के साथ संगतता बनाए रखने के लिए सर्वर द्वारा केवल पथ नाम वाली एक अनुरोध पंक्ति स्वीकार किया जाती है।^[43]

अनुरोध की विधियां

टेलनेट का उपयोग करके किया गया एचटीटीपी/1.1 अनुरोध। एचटीटीपी रिक्वेस्ट मैसेज, एचटीटीपी रिस्पांस हेडर सेक्शन और रिस्पॉन्स बॉडी हाइलाइट की गई हैं।

एचटीटीपी विधियों को परिभाषित करता है (कभी-कभी क्रियाओं के रूप में संदर्भित किया जाता है, लेकिन कहीं भी विनिर्देशन में यह क्रिया का उल्लेख नहीं करता है) पहचाने गए संसाधन पर वांछित क्रिया को निरुपित करने के लिए किया जाता हैं। यह संसाधन क्या दर्शाता है, चाहे पूर्व-विद्यमान डेटा या डेटा जो गतिशील रूप से उत्पन्न होता है, और सर्वर के कार्यान्वयन पर निर्भर करता है। अधिकांश, संसाधन फ़ाइल या सर्वर पर निष्पादन योग्य के आउटपुट से मेल खाता है। एचटीटीपी/1.0 विनिर्देश^[44] ने जीईटी, हेड और पोस्ट विधियों को परिभाषित किया और एचटीटीपी / 1.1 विनिर्देश ने^[45] पांच नए विधियां जोड़े: पुट, डिलीट, कनेक्ट, ऑप्शन और ट्रेस। कोई भी क्लाइंट किसी भी विधि का उपयोग कर सकता है और सर्वर को विधियों के किसी भी संयोजन का समर्थन करने के लिए कॉन्फ़िगर किया जा सकता है। यदि कोई विधि किसी मध्यवर्ती के लिए अज्ञात है, तो इसे एक असुरक्षित और आलस्य के रूप में माना जाएगा। परिभाषित किए जा सकने वाले विधियों की संख्या की कोई सीमा नहीं है, जो विद्यमान मूलभूत संरचना को तोड़े बिना भविष्य के विधियों को निर्दिष्ट करने की अनुमति देता है। उदाहरण के लिए, वेबडीएवी ने सात नई विधियों को परिभाषित किया और RFC 5789 पैच क्रिया विधि निर्दिष्ट किया था।

विधि के नाम केस संवेदी होते हैं।^[46]^[47] यह एचटीटीपी शीर्षलेख फ़ील्ड नामों के विपरीत है जो केस-असंवेदनशील हैं।^[48]

प्राप्त करें: जीईटी विधि अनुरोध करती है कि लक्ष्य संसाधन अपने राज्य का प्रतिनिधित्व स्थानांतरित करे। जीईटी अनुरोधों को केवल डेटा पुनर्प्राप्ति होना चाहिए और इसका कोई अन्य प्रभाव नहीं होना चाहिए। (यह कुछ अन्य एचटीटीपी विधियों के लिए भी सही है।)^[1]परिवर्तन किए बिना संसाधनों को पुनः प्राप्त करने के लिए, पोस्ट पर जीईटी को प्राथमिकता दी जाती है, क्योंकि वे एक यूआरएल के माध्यम से पता योग्यता हो सकते हैं। यह बुकमार्क करने और साझा करने में सक्षम बनाता है और ब्राउज़र कैश के लिए प्रतिक्रिया प्राप्त करता है, जो बैंडविड्थ को बचा सकता है। W3C ने इस भेद पर मार्गदर्शन सिद्धांतों को प्रकाशित किया है, जिसमें कहा गया है, "वेब एप्लिकेशन डिज़ाइन को उपरोक्त सिद्धांतों द्वारा लेकिन प्रासंगिक सीमाओं द्वारा भी सूचित किया जाना चाहिए।^[49] नीचे सुरक्षित विधियां देखें।

हेड: हेड विधि अनुरोध करती है कि लक्ष्य संसाधन अपने राज्य का एक प्रतिनिधित्व स्थानांतरित करता है, जैसा कि जीईटी अनुरोध के लिए होता है, लेकिन प्रतिक्रिया निकाय में संलग्न प्रतिनिधित्व डेटा के बिना। यह प्रतिक्रिया शीर्षलेख में प्रतिनिधित्व मेटाडेटा को पुनर्प्राप्त करने के लिए उपयोगी है, पूरे प्रतिनिधित्व को स्थानांतरित किए बिना। इसके उपयोगों में यह जांचना सम्मिलित है कि एचटीटीपी स्थिति कोड के माध्यम से कोई पृष्ठ उपलब्ध है या नहीं और कम्प्यूटर फाइल के आकार (Content-Length) का शीघ्रता से पता लगाता हैं।

पोस्ट: पोस्ट (एचटीटीपी) अनुरोध करता है कि लक्ष्य संसाधन लक्ष्य संसाधन के शब्दार्थ के अनुसार अनुरोध में संलग्न प्रतिनिधित्व को संसाधित करता है। उदाहरण के लिए, इसका उपयोग इंटरनेट मंच पर संदेश पोस्ट करने, मेलिंग सूची की सदस्यता लेने या ऑनलाइन खरीदारी लेनदेन को पूरा करने के लिए किया जाता है।^[50]

पुट: पुट विधि अनुरोध करती है कि लक्ष्य संसाधन अनुरोध में संलग्न प्रतिनिधित्व द्वारा परिभाषित राज्य के साथ अपने राज्य को बनाएं या अपडेट करें। पोस्ट से एक अंतर यह है कि क्लाइंट सर्वर पर लक्ष्य स्थान निर्दिष्ट करता है।^[51]

डिलीट: डिलीट विधि अनुरोध करती है कि लक्ष्य संसाधन अपनी स्थिति को हटा दें।

कनेक्ट: कनेक्ट विधि अनुरोध करती है कि मध्यस्थ अनुरोध लक्ष्य द्वारा पहचाने गए मूल सर्वर के लिए एक टनलिंग प्रोटोकॉल | टीसीपी / आईपी सुरंग स्थापित करता है। इसका उपयोग अधिकांश ट्रांसपोर्ट लेयर सिक्योरिटी के साथ एक या एक से अधिक एचटीटीपी प्रॉक्सी के माध्यम से कनेक्शन सुरक्षित करने के लिए किया जाता है।^[52]^[53] एचटीटीपी टनल एचटीटीपी कनेक्ट विधि देखें।

विकल्प: विकल्प विधि अनुरोध करती है कि लक्ष्य संसाधन एचटीटीपी विधियों को स्थानांतरित करता है जो इसका समर्थन करता है। इसका उपयोग किसी विशिष्ट संसाधन के अतिरिक्त '*' अनुरोध करके वेब सर्वर की कार्यक्षमता की जांच करने के लिए किया जा सकता है।

पता लगाना: ट्रेस विधि अनुरोध करती है कि लक्ष्य संसाधन प्रतिक्रिया निकाय में प्राप्त अनुरोध को स्थानांतरित कर दे। इस तरह एक ग्राहक देख सकता है कि बिचौलियों द्वारा क्या (यदि कोई हो) परिवर्तन या परिवर्धन किया गया है।

पैच: पैच क्रिया अनुरोध करती है कि लक्ष्य संसाधन अनुरोध में संलग्न प्रतिनिधित्व में परिभाषित आंशिक अद्यतन के अनुसार अपनी स्थिति को संशोधित करता है। यह किसी फ़ाइल या दस्तावेज़ को पूरी तरह से स्थानांतरित किए बिना उसका एक हिस्सा अपडेट करके बैंडविड्थ को बचा सकता है।^[54]

सभी सामान्य-उद्देश्य वाले वेब सर्वरों को कम से कम जीईटी और हेड विधियों को प्रायुक्त करने की आवश्यकता होती है, और अन्य सभी विधियों को विनिर्देश द्वारा वैकल्पिक माना जाता है।^[47]

Properties of request methods
अनुरोध विधि	आरएफसी	अनुरोध में पेलोड बॉडी है	प्रतिक्रिया में पेलोड बॉडी है	सुरक्षित	निर्बल	संचित करने योग्य
जीईटी	RFC 9110	Optional	Yes	Yes	Yes	Yes
हेड	RFC 9110	Optional	No	Yes	Yes	Yes
पोस्ट	RFC 9110	Yes	Yes	No	No	Yes
पुट	RFC 9110	Yes	Yes	No	Yes	No
डिलीट	RFC 9110	Optional	Yes	No	Yes	No
कनेक्ट	RFC 9110	Optional	Yes	No	No	No
ऑप्शन	RFC 9110	Optional	Yes	Yes	Yes	No
पता लगाना	RFC 9110	No	Yes	Yes	Yes	No
पैच	RFC 5789	Yes	Yes	No	No	No

सुरक्षित विधियां

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

इसके विपरीत, पोस्ट, पुट, डिलीट, कनेक्ट, और पैच की विधियां सुरक्षित नहीं हैं। वे सर्वर की स्थिति को संशोधित कर सकते हैं या ईमेल भेजने जैसे अन्य प्रभाव डाल सकते हैं। इस तरह की विधियां सामान्यतः इंटरनेट बॉट या वेब क्रॉलर के अनुरूप नहीं होते हैं; कुछ जो अनुरूप नहीं हैं, वे संदर्भ या परिणामों की परवाह किए बिना अनुरोध करते हैं।

जीईटी अनुरोधों की निर्धारित सुरक्षा के अतिरिक्त, व्यवहार में सर्वर द्वारा उनकी हैंडलिंग किसी भी तरह से तकनीकी रूप से सीमित नहीं है। लापरवाह या जानबूझकर अनियमित प्रोग्रामिंग जीईटी अनुरोधों को सर्वर पर गैर-तुच्छ परिवर्तन करने की अनुमति दे सकती है। वेब कैशिंग, खोज इंजन और अन्य स्वचालित एजेंटों द्वारा सर्वर पर अनपेक्षित परिवर्तन करने पर उत्पन्न होने वाली समस्याओं के कारण इसे हतोत्साहित किया जाता है। उदाहरण के लिए, एक वेबसाइट https://example.com/article/1234/delete जैसे किसी यूआरएल के माध्यम से किसी संसाधन को हटाने की अनुमति दे सकती है, जो, यदि स्वैच्छिक ढंग से प्राप्त किया जाता है, यहां तक कि जीईटी का उपयोग करके, बस हटा दिया जाएगा लेख।^[55] एक ठीक से कोडित वेबसाइट को इस क्रिया के लिए डिलीट या पोस्ट विधि की आवश्यकता होगी, जो गैर-दुर्भावनापूर्ण बॉट्स नहीं करेंगे।

अभ्यास में ऐसा होने का एक उदाहरण अल्पकालिक गूगल वेब त्वरक बीटा परीक्षण के समय था, जो एक उपयोगकर्ता द्वारा देखे जा रहे पृष्ठ पर स्वैच्छिक यूआरएल प्रीफ़ेच करता था, जिससे रिकॉर्ड स्वचालित रूप से बदल जाते थे या सामूहिक रूप से हटा दिए जाते थे। व्यापक आलोचना के बाद, बीटा को इसकी पहली रिलीज के कुछ सप्ताह बाद ही निलंबित कर दिया गया था।^[56]^[55]

निष्काम विधियां

एक अनुरोध विधि उदासीन है यदि उस विधि के साथ कई समान अनुरोधों का एक ही अनुरोध के समान प्रभाव होता है। पुट और डिलीट की विधियां, और सुरक्षित विधियों को idempotent के रूप में परिभाषित किया गया है। सुरक्षित विधियां तुच्छ रूप से व्यर्थ हैं, क्योंकि उनका इरादा सर्वर पर किसी भी तरह का प्रभाव नहीं डालना है; इस बीच, पुट और डिलीट विधियाँ उदासीन हैं क्योंकि क्रमिक समान अनुरोधों को अनदेखा कर दिया जाएगा। उदाहरण के लिए, एक वेबसाइट उपयोगकर्ता के रिकॉर्ड किए गए ईमेल पते को संशोधित करने के लिए एक पुट समापन बिंदु सेट कर सकती है। यदि यह समापन बिंदु सही ढंग से कॉन्फ़िगर किया गया है, तो कोई भी अनुरोध जो उपयोगकर्ता के ईमेल पते को उसी ईमेल पते में बदलने के लिए कहता है जो पहले से ही रिकॉर्ड किया गया है—उदा. एक सफल अनुरोध के बाद डुप्लिकेट अनुरोध—कोई प्रभाव नहीं पड़ेगा। इसी प्रकार, किसी निश्चित उपयोगकर्ता को हटाने के अनुरोध का कोई प्रभाव नहीं पड़ेगा यदि वह उपयोगकर्ता पहले ही हटा दिया गया हो।

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

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

प्राप्य विधियां

एक अनुरोध विधि कैश करने योग्य है यदि उस विधि के अनुरोधों के उत्तर भविष्य में पुन: उपयोग के लिए संग्रहीत किए जा सकते हैं। विधियों जीईटी, हेड और पोस्ट को कैश करने योग्य के रूप में परिभाषित किया गया है।

इसके विपरीत, पुट, डिलीट, कनेक्ट, ऑप्शन, ट्रेस और पैच की विधियां उपलब्ध नहीं हैं।

हेडर फ़ील्ड का अनुरोध करें

अनुरोध शीर्षलेख फ़ील्ड क्लाइंट को अनुरोध संशोधक (एक प्रक्रिया के पैरामीटर के समान) के रूप में कार्य करते हुए अनुरोध पंक्ति से परे अतिरिक्त जानकारी पास करने की अनुमति देती है। वे ग्राहक के बारे में, लक्ष्य संसाधन के बारे में, या अनुरोध के अपेक्षित संचालन के बारे में जानकारी देते हैं।

एचटीटीपी/1.1 प्रतिक्रिया संदेश

एक प्रतिक्रिया संदेश एक सर्वर द्वारा क्लाइंट को उसके पूर्व अनुरोध संदेश के उत्तर के रूप में भेजा जाता है।^{[note 4]}

प्रतिक्रिया सिंटैक्स

एक सर्वर क्लाइंट को प्रतिक्रिया संदेश भेजता है, जिसमें सम्मिलित हैं:^[42]

एक स्टेटस लाइन, जिसमें प्रोटोकॉल संस्करण, एक स्पेस (विराम चिह्न), एचटीटीपी स्टेटस कोड की सूची, एक अन्य स्पेस, एक संभावित खाली कारण वाक्यांश, एक कैरिज रिटर्न और एक लाइन फीड सम्मिलित है, उदाहरण के लिए:

HTTP/1.1 200 OK

शून्य या अधिक एचटीटीपी प्रतिक्रिया शीर्षलेख फ़ील्ड, प्रत्येक में केस-असंवेदनशील फ़ील्ड नाम, एक कोलन, वैकल्पिक अग्रणी व्हाइटस्पेस (कंप्यूटर विज्ञान), फ़ील्ड मान, एक वैकल्पिक अनुगामी व्हाइटस्पेस और एक कैरिज रिटर्न और एक लाइन फीड के साथ समाप्त होता है, उदाहरण के लिए :

Content-Type: text/html

एक खाली लाइन, जिसमें कैरिज रिटर्न और लाइन फीड सम्मिलित है;
एक वैकल्पिक एचटीटीपी संदेश निकाय।

प्रतिक्रिया स्थिति कोड

एचटीटीपी/1.0 में और उसके बाद से, एचटीटीपी प्रतिक्रिया की पहली पंक्ति को स्थिति रेखा कहा जाता है और इसमें एक संख्यात्मक स्थिति कोड (जैसे एचटीटीपी 404) और एक शाब्दिक कारण वाक्यांश (जैसे नहीं मिला) सम्मिलित होता है। प्रतिक्रिया स्थिति कोड एक तीन अंकों का पूर्णांक कोड है जो क्लाइंट के संबंधित अनुरोध को समझने और संतुष्ट करने के सर्वर के प्रयास के परिणाम का प्रतिनिधित्व करता है। जिस तरह से ग्राहक प्रतिक्रिया को संभालता है वह मुख्य रूप से स्थिति कोड पर निर्भर करता है, और दूसरा प्रतिक्रिया हेडर फ़ील्ड पर। ग्राहक सभी पंजीकृत स्थिति कोड को नहीं समझ सकते हैं, लेकिन उन्हें अपनी कक्षा (स्थिति कोड के पहले अंक द्वारा दी गई) को समझना चाहिए और उस वर्ग के x00 स्थिति कोड के बराबर होने के लिए एक गैर-मान्यता प्राप्त स्थिति कोड का इलाज करना चाहिए।

मानक कारण वाक्यांश केवल अनुशंसाएँ हैं, और वेब डेवलपर के विवेक पर स्थानीय समकक्षों के साथ बदले जा सकते हैं। यदि स्थिति कोड किसी समस्या का संकेत देता है, तो उपयोगकर्ता एजेंट समस्या की प्रकृति के बारे में अधिक जानकारी प्रदान करने के लिए उपयोगकर्ता को कारण वाक्यांश प्रदर्शित कर सकता है। मानक भी उपयोगकर्ता एजेंट को कारण वाक्यांश की व्याख्या करने का प्रयास करने की अनुमति देता है, चूंकि यह नासमझी हो सकती है क्योंकि मानक स्पष्ट रूप से निर्दिष्ट करता है कि स्थिति कोड मशीन-पठनीय हैं और कारण वाक्यांश मानव-पठनीय हैं।

स्थिति कोड का पहला अंक इसकी कक्षा को परिभाषित करता है:

1XX (सूचनात्मक): अनुरोध प्राप्त हुआ, प्रक्रिया जारी है।

2XX (सफल): अनुरोध सफलतापूर्वक प्राप्त हुआ, समझा गया और स्वीकार किया गया।

3XX (पुनर्निर्देशन): अनुरोध को पूरा करने के लिए आगे की कार्रवाई करने की आवश्यकता है।

4XX (क्लाइंट त्रुटि): अनुरोध में खराब सिंटैक्स है या इसे पूरा नहीं किया जा सकता है।

5XX (सर्वर त्रुटि): सर्वर स्पष्ट रूप से मान्य अनुरोध को पूरा करने में विफल रहा।

प्रतिक्रिया शीर्षलेख फ़ील्ड

प्रतिक्रिया शीर्षलेख फ़ील्ड सर्वर को प्रतिक्रिया संशोधक के रूप में कार्य करते हुए स्थिति रेखा से परे अतिरिक्त जानकारी पास करने की अनुमति देती है। वे सर्वर के बारे में या लक्षित संसाधन या संबंधित संसाधनों तक और पहुंच के बारे में जानकारी देते हैं।

प्रत्येक प्रतिक्रिया हेडर फ़ील्ड का एक परिभाषित अर्थ होता है जिसे अनुरोध विधि या प्रतिक्रिया स्थिति कोड के शब्दार्थ द्वारा और अधिक परिष्कृत किया जा सकता है।

एचटीटीपी/1.1 अनुरोध/प्रतिक्रिया लेनदेन का उदाहरण

नीचे एक एचटीटीपी/1.1 क्लाइंट और एक एचटीटीपी/1.1 सर्वर के बीच एक नमूना एचटीटीपी लेनदेन है जो example.com|www.example.com, पोर्ट 80 पर चल रहा है।^{[note 5]}^{[note 6]}

क्लाइंट अनुरोध

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

एक क्लाइंट अनुरोध (अनुरोध पंक्ति के इस स्थिति में और कुछ शीर्षलेख सम्मिलित हैं जिन्हें केवल "Host: hostname" हेडर) के बाद एक खाली लाइन होती है, जिससे अनुरोध लाइन के दोहरे अंत के साथ समाप्त हो, प्रत्येक कैरिज रिटर्न के रूप में और उसके बाद लाइन फीड हो। "Host: hostname" e> शीर्ष लेख मान विभिन्न डॉमेन नाम प्रणाली नामों के बीच एक एकल आईपी पता साझा करने के बीच अंतर करता है, जिससे नाम-आधारित वर्चुअल होस्टिंग की अनुमति मिलती है। जबकि एचटीटीपी/1.0 में वैकल्पिक है, एचटीटीपी/1.1 में यह अनिवार्य है। (ए / (स्लैश) सामान्यतः एक वेबसर्वर डायरेक्टरी /index.html फ़ाइल लाएगा यदि कोई है।)

सर्वर प्रतिक्रिया

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

एचटीटीपी ईटैग (एंटिटी टैग) हेडर फ़ील्ड का उपयोग यह निर्धारित करने के लिए किया जाता है कि अनुरोधित संसाधन का कैश्ड संस्करण सर्वर पर संसाधन के वर्तमान संस्करण के समान है या नहीं। "Content-Type" एचटीटीपी संदेश द्वारा बताए गए डेटा के इंटरनेट मीडिया प्रकार को निर्दिष्ट करता है, जबकि "Content-Length" बाइट्स में इसकी लंबाई निरुपित करता है। एचटीटीपी/1.1 वेबसर्वर फ़ील्ड सेट करके दस्तावेज़ की कुछ बाइट श्रेणियों के अनुरोधों का उत्तर देने की अपनी क्षमता प्रकाशित करता है "Accept-Ranges: bytes". यह उपयोगी है, यदि ग्राहक को केवल कुछ हिस्से ही चाहिए^[57] सर्वर द्वारा भेजे गए संसाधन का, जिसे बाइट सर्विंग कहा जाता है। कब "Connection: close" भेजा जाता है, तो इसका अर्थ है कि वेब सर्वर इस प्रतिक्रिया के हस्तांतरण के अंत के तुरंत बाद ट्रांसमिशन कंट्रोल प्रोटोकॉल कनेक्शन बंद कर देगा।^[18]

अधिकांश हेडर लाइन वैकल्पिक हैं लेकिन कुछ अनिवार्य हैं। जब हेडर "Content-Length: number" एक इकाई निकाय के साथ प्रतिक्रिया में गुम है तो इसे एचटीटीपी/1.0 में एक त्रुटि माना जाना चाहिए लेकिन हेडर होने पर एचटीटीपी/1.1 में यह त्रुटि नहीं हो सकती है "Transfer-Encoding: chunked" उपस्थित है। चंक्ड ट्रांसफर एन्कोडिंग सामग्री के अंत को चिह्नित करने के लिए 0 के चंक आकार का उपयोग करता है। एचटीटीपी/1.0 के कुछ पुराने कार्यान्वयनों ने हेडर को छोड़ दिया "Content-Length" जब प्रतिक्रिया के प्रारंभ में शरीर इकाई की लंबाई ज्ञात नहीं थी और इसलिए क्लाइंट को डेटा का स्थानांतरण तब तक जारी रहा जब तक कि सर्वर ने सॉकेट बंद नहीं कर दिया।

एक "Content-Encoding: gzip" क्लाइंट को सूचित करने के लिए उपयोग किया जा सकता है कि ट्रांसमिटेड डेटा का बॉडी एंटिटी पार्ट gzip एल्गोरिथम द्वारा कंप्रेस किया गया है।

एन्क्रिप्टेड कनेक्शन

एन्क्रिप्टेड एचटीटीपी कनेक्शन स्थापित करने का सबसे लोकप्रिय विधि एचटीटीपीएस है।^[58] एन्क्रिप्टेड एचटीटीपी कनेक्शन स्थापित करने के लिए दो अन्य विधियां भी उपस्थित हैं: सुरक्षित हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल, और टीएलएस में अपग्रेड निर्दिष्ट करने के लिए एचटीटीपी/1.1 अपग्रेड हेडर का उपयोग करना। चूँकि, इन दोनों के लिए ब्राउज़र समर्थन लगभग न के बराबर है।^[59]^[60]^[61]

समान प्रोटोकॉल

गोफर (प्रोटोकॉल) एक सामग्री वितरण प्रोटोकॉल है जिसे 1990 के दशक के प्रारंभ में एचटीटीपी द्वारा विस्थापित किया गया था।
स्पीडी प्रोटोकॉल, गूगल द्वारा विकसित एचटीटीपी का एक विकल्प है, जिसका स्थान एचटीटीपी/2 ने ले लिया है।
मिथुन (प्रोटोकॉल) एक गोफर-प्रेरित प्रोटोकॉल है जो गोपनीयता से संबंधित सुविधाओं को अनिवार्य करता है।

यह भी देखें

अंतर्ग्रहीय फाइल प्रणाली - एचटीटीपी की जगह ले सकता है
फ़ाइल स्थानांतरण प्रोटोकॉल की तुलना
विवश एप्लीकेशन प्रोटोकॉल - एचटीटीपी के लिए शब्दार्थ के समान प्रोटोकॉल लेकिन सीमित प्रसंस्करण क्षमता वाले उपकरणों के लिए लक्षित यूडीपी या यूडीपी जैसे संदेशों का उपयोग किया जाता है; एचटीटीपी और इंटरनेट मीडिया प्रकार और वेब लिंकिंग जैसी अन्य इंटरनेट अवधारणाओं का पुन: उपयोग करता है (आरएफसी 5988)^[62]
सामग्री बातचीत
डाइजेस्ट एक्सेस ऑथेंटिकेशन
एचटीटीपी संपीड़न
एचटीटीपी/2 - आईईटीएफ के हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (httpbis) वर्किंग ग्रुप द्वारा विकसित किया गया^[63]
एचटीटीपी शीर्षलेख फ़ील्ड की सूची
एचटीटीपी स्थिति कोड की सूची
प्रतिनिधित्वात्मक राज्य स्थानांतरण (आरईएसटी)
भिन्न वस्तु
वेब कैश
वेबसॉकेट

↑ In practice, these streams are used as multiple TCP/IP sub-connections to multiplex concurrent requests/responses, thus greatly reducing the number of real TCP/IP connections on server side, from 2..8 per client to 1, and allowing many more clients to be served at once.
↑ In 2022, HTTP/0.9 support has not been officially completely deprecated and is still present in many web servers and browsers (for server responses only), even if usually disabled. It is unclear how long it will take to decommission HTTP/0.9.
↑ Since late 1996, some developers of popular HTTP/1.0 browsers and servers (specially those who had planned support for HTTP/1.1 too), started to deploy (as an unofficial extension) a sort of keep-alive-mechanism (by using new HTTP headers) in order to keep the TCP/IP connection open for more than a request/response pair and so to speed up the exchange of multiple requests/responses.^[29]
↑ ^{Jump up to: 4.0} ^4.1 HTTP/2 and HTTP/3 have a different representation for HTTP methods and headers.
↑ HTTP/1.0 has the same messages except for a few missing headers.
↑ HTTP/2 and HTTP/3 use the same request / response mechanism but with different representations for HTTP headers.

संदर्भ

↑ ^{Jump up to: 1.0} ^1.1 ^1.2 ^1.3 Fielding, R.; Nottingham, M.; Reschke, J. (June 2022). HTTP Semantics. IETF. doi:10.17487/RFC9110. RFC 9110.
↑ ^{Jump up to: 2.0} ^2.1 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org (in English). World Wide Web Consortium. Retrieved 2021-10-19.</रेफरी> टिप्पणियों के लिए शुरुआती HTTP अनुरोधों (RFCs) का विकास कुछ साल बाद शुरू हुआ और यह इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) और वर्ल्ड वाइड वेब कंसोर्टियम (W3C) द्वारा एक समन्वित प्रयास था, जिसका काम बाद में IETF में चला गया। HTTP/1 को 1996 में अंतिम रूप दिया गया और पूरी तरह से प्रलेखित किया गया (संस्करण 1.0 के रूप में)। रेफरी> में RFC 1945. उस विनिर्देशन को तब HTTP/1.1 द्वारा समाप्त कर दिया गया था।
↑ "Usage Statistics of Default protocol https for websites". w3techs.com. Retrieved 2022-10-16.
↑ "Usage Statistics of HTTP/2 for websites". w3techs.com. Retrieved 2022-12-02.
↑ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 2022-10-16.
↑ "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". IETF. July 2014. RFC 7301.
↑ Belshe, M.; Peon, R.; Thomson, M. "Hypertext Transfer Protocol Version 2, Use of TLS Features". Archived from the original on 2013-07-15. Retrieved 2015-02-10.
↑ Benjamin, David. "Using TLS 1.3 with HTTP/2". tools.ietf.org (in English). Retrieved 2020-06-02. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.
↑ "HTTP/3" (in English). Retrieved 2022-06-06.
↑ "Usage Statistics of HTTP/3 for websites". w3techs.com. Retrieved 2022-10-16.
↑ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 2022-10-16.
↑ Cimpanu, Catalin (26 September 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved 27 September 2019.
↑ "HTTP/3: the past, the present, and the future". The Cloudflare Blog (in English). 2019-09-26. Retrieved 2019-10-30.
↑ "Firefox Nightly supports HTTP 3 - General - Cloudflare Community". 2019-11-19. Retrieved 2020-01-23.
↑ "HTTP/3 is Fast". Request Metrics (in English). Retrieved 2022-07-01.
↑ ^{Jump up to: 16.0} ^16.1 ^16.2 "Connections, Clients, and Servers". RFC 9110, HTTP Semantics. sec. 3.3. doi:10.17487/RFC9110. RFC 9110.
↑ "Overall Operation". RFC 1945. pp. 6–8. sec. 1.3. doi:10.17487/RFC1945. RFC 1945.
↑ ^{Jump up to: 18.0} ^18.1 ^18.2 "Connection Management: Establishment". RFC 9112, HTTP/1.1. sec. 9.1. doi:10.17487/RFC9112. RFC 9112.
↑ "Connection Management: Persistence". RFC 9112, HTTP/1.1. sec. 9.3. doi:10.17487/RFC9112. RFC 9112.
↑ "Classic HTTP Documents". W3.org. 1998-05-14. Retrieved 2010-08-01.
↑ "HTTP/2 Protocol Overview". RFC 9113, HTTP/2). sec. 2. doi:10.17487/RFC7540. RFC 7540.
↑ "Invention Of The Web, Web History, Who Invented the Web, Tim Berners-Lee, Robert Cailliau, CERN, First Web Server". LivingInternet (in English). Retrieved 2021-08-11.
↑ Berners-Lee, Tim (1990-10-02). "daemon.c - TCP/IP based server for HyperText". www.w3.org. Retrieved 2021-08-11.
↑ Berners-Lee, Tim. "HyperText Transfer Protocol". World Wide Web Consortium. Retrieved 31 August 2010.
↑ ^{Jump up to: 25.0} ^25.1 ^25.2 Cite error: Invalid <ref> tag; no text was provided for refs named HTTP/0.9-specifications
↑ Raggett, Dave. "Dave Raggett's Bio". World Wide Web Consortium. Retrieved 11 June 2010.
↑ Raggett, Dave; Berners-Lee, Tim. "Hypertext Transfer Protocol Working Group". World Wide Web Consortium. Retrieved 29 September 2010.
↑ Raggett, Dave. "HTTP WG Plans". World Wide Web Consortium. Retrieved 29 September 2010.
↑ ^{Jump up to: 29.0} ^29.1 David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections") (in English). O'Reilly Media, inc. ISBN 9781565925090. Retrieved 2021-10-18.
↑ "HTTP/1.1". Webcom.com Glossary entry. Archived from the original on 2001-11-21. Retrieved 2009-05-29.
↑ "HTTP-NG Working Group". www.w3.org (in English). World Wide Web Consortium. 1997. Retrieved 2021-10-19.
↑ Web Administrator (2007). "HTTP Working Group". httpwg.org (in English). IETF. Retrieved 2021-10-19.
↑ Web Administrator (2007). "HTTP Working Group: charter httpbis". datatracker.ietf.org (in English). IETF. Retrieved 2021-10-19.
↑ "एसपीडीवाई: तेज़ वेब के लिए एक प्रयोगात्मक प्रोटोकॉल". dev.chromium.org (in English). Google. 2009-11-01. Retrieved 2021-10-19.
↑ IESG Secretary (2012-03-19). "WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)" (in English). IETF; HTTP WG. Retrieved 2021-10-19.
↑ Ilya Grigorik; Surma (2019-09-03). "उच्च निष्पादन ब्राउज़र नेटवर्किंग: HTTP/2 का परिचय". developers.google.com (in English). Google Inc. Retrieved 2021-10-19.
↑ Matt Menke (2016-06-30). "बहिष्कृत करने और निकालने का इरादा: HTTP/0.9 समर्थन". groups.google.com (in English). Retrieved 2021-10-15.
↑ "HTTP/3" (in English). Retrieved 2022-06-06.
↑ "http URI Scheme". RFC 9110, HTTP Semantics. sec. 4.2.1. doi:10.17487/RFC9110. RFC 9110.
↑ "https URI Scheme". RFC 9110, HTTP Semantics. sec. 4.2.2. doi:10.17487/RFC9110. RFC 9110.
↑ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019-01-25). "Secure and efficient protection for HTTP cookies with self-verification". International Journal of Communication Systems (in English). 32 (2): e3857. doi:10.1002/dac.3857. S2CID 59524143.
↑ ^{Jump up to: 42.0} ^42.1 "Message format". RFC 9112: HTTP/1.1. sec. 2.1. doi:10.17487/RFC9112. RFC 9112.
↑ "अपाचे वीक। एचटीटीपी/1.1". 090502 apacheweek.com
↑ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. "Method Definitions". Hypertext Transfer Protocol – HTTP/1.0. IETF. pp. 30–32. sec. 8. doi:10.17487/RFC1945. RFC 1945.
↑ "Method Definitions". RFC 2616. pp. 51–57. sec. 9. doi:10.17487/RFC2616. RFC 2616.
↑ "Request Line". RFC 9112, HTTP/1.1. sec. 3. doi:10.17487/RFC9112. RFC 9112.
↑ ^{Jump up to: 47.0} ^47.1 "Methods: Overview". RFC 9110, HTTP Semantics. sec. 9.1. doi:10.17487/RFC9110. RFC 9110.
↑ "Header Fields". RFC 9110, HTTP Semantics. sec. 6.3. doi:10.17487/RFC9110. RFC 9110.
↑ Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Technical Architecture Group finding. W3C. Retrieved 26 September 2010.
↑ "POST". RFC 9110, HTTP Semantics. sec. 9.3.3. doi:10.17487/RFC9110. RFC 9110.
↑ "PUT". RFC 9110, HTTP Semantics. sec. 9.3.4. doi:10.17487/RFC9110. RFC 9110.
↑ "CONNECT". RFC 9110, HTTP Semantics. sec. 9.3.6. doi:10.17487/RFC9110. RFC 9110.
↑ "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. Retrieved 2007-05-10.
↑ Dusseault, Lisa; Snell, James M. (March 2010). PATCH Method for HTTP. IETF. doi:10.17487/RFC5789. RFC 5789.
↑ ^{Jump up to: 55.0} ^55.1 Ediger, Brad (2007-12-21). Advanced Rails: Building Industrial-Strength Web Apps in Record Time. O'Reilly Media, Inc. p. 188. ISBN 978-0596519728. A common mistake is to use GET for an action that updates a resource. [...] This problem came into the Rails public eye in 2005, when the Google Web Accelerator was released.
↑ Cantrell, Christian (2005-06-01). "What Have We Learned From the Google Web Accelerator?". Adobe Blogs. Adobe. Archived from the original on 2017-08-19. Retrieved 2018-11-19.
↑ Luotonen, Ari; Franks, John (February 22, 1996). Byte Range Retrieval Extension to HTTP. IETF. I-D draft-ietf-http-range-retrieval-00.
↑ Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83. ISBN 9781580531764.
↑ Zalewski, Michal. "Browser Security Handbook". Retrieved 30 April 2015.
↑ "Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1". Retrieved 30 April 2015.
↑ "Mozilla Bug 276813 – [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1". Retrieved 30 April 2015.
↑ Nottingham, Mark (October 2010). Web Linking. IETF. doi:10.17487/RFC5988. RFC 5988.
↑ "Hypertext Transfer Protocol Bis (httpbis) – Charter". IETF. 2012.

बाहरी कड़ियाँ

No URL found. Please specify a URL here or add one to Wikidata.
IETF HTTP Working Group on GitHub

"Change History for HTTP". W3.org. Retrieved 2010-08-01. A detailed technical history of HTTP.
"Design Issues for HTTP". W3.org. Retrieved 2010-08-01. Design Issues by Berners-Lee when he was designing the protocol.

[21] In practice, these streams are used as multiple TCP/IP sub-connections to multiplex concurrent requests/responses, thus greatly reducing the number of real TCP/IP connections on server side, from 2..8 per client to 1, and allowing many more clients to be served at once.

[39] In 2022, HTTP/0.9 support has not been officially completely deprecated and is still present in many web servers and browsers (for server responses only), even if usually disabled. It is unclear how long it will take to decommission HTTP/0.9.

[43] Since late 1996, some developers of popular HTTP/1.0 browsers and servers (specially those who had planned support for HTTP/1.1 too), started to deploy (as an unofficial extension) a sort of keep-alive-mechanism (by using new HTTP headers) in order to keep the TCP/IP connection open for more than a request/response pair and so to speed up the exchange of multiple requests/responses.^[29]

[http-23-message-45] {Jump up to: 4.0} ^4.1 HTTP/2 and HTTP/3 have a different representation for HTTP methods and headers.

[61] HTTP/1.0 has the same messages except for a few missing headers.

[62] HTTP/2 and HTTP/3 use the same request / response mechanism but with different representations for HTTP headers.

[rfc9110-1] {Jump up to: 1.0} ^1.1 ^1.2 ^1.3 Fielding, R.; Nottingham, M.; Reschke, J. (June 2022). HTTP Semantics. IETF. doi:10.17487/RFC9110. RFC 9110.

[HTTP/1.0-first-unofficial-draft-2] {Jump up to: 2.0} ^2.1 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org (in English). World Wide Web Consortium. Retrieved 2021-10-19.</रेफरी> टिप्पणियों के लिए शुरुआती HTTP अनुरोधों (RFCs) का विकास कुछ साल बाद शुरू हुआ और यह इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) और वर्ल्ड वाइड वेब कंसोर्टियम (W3C) द्वारा एक समन्वित प्रयास था, जिसका काम बाद में IETF में चला गया। HTTP/1 को 1996 में अंतिम रूप दिया गया और पूरी तरह से प्रलेखित किया गया (संस्करण 1.0 के रूप में)। रेफरी> में RFC 1945. उस विनिर्देशन को तब HTTP/1.1 द्वारा समाप्त कर दिया गया था।

[HTTPS-usage-web-servers-3] "Usage Statistics of Default protocol https for websites". w3techs.com. Retrieved 2022-10-16.

[HTTP2-usage-web-servers-4] "Usage Statistics of HTTP/2 for websites". w3techs.com. Retrieved 2022-12-02.

[HTTP2-Can-I-Use-5] "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 2022-10-16.

[rfc7301-6] "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". IETF. July 2014. RFC 7301.

[7] Belshe, M.; Peon, R.; Thomson, M. "Hypertext Transfer Protocol Version 2, Use of TLS Features". Archived from the original on 2013-07-15. Retrieved 2015-02-10.

[8] Benjamin, David. "Using TLS 1.3 with HTTP/2". tools.ietf.org (in English). Retrieved 2020-06-02. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.

[9] "HTTP/3" (in English). Retrieved 2022-06-06.

[HTTP3-usage-web-servers-10] "Usage Statistics of HTTP/3 for websites". w3techs.com. Retrieved 2022-10-16.

[HTTP3-Can-I-Use-11] "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 2022-10-16.

[12] Cimpanu, Catalin (26 September 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved 27 September 2019.

[13] "HTTP/3: the past, the present, and the future". The Cloudflare Blog (in English). 2019-09-26. Retrieved 2019-10-30.

[14] "Firefox Nightly supports HTTP 3 - General - Cloudflare Community". 2019-11-19. Retrieved 2020-01-23.

[15] "HTTP/3 is Fast". Request Metrics (in English). Retrieved 2022-07-01.

[rfc9110-3.3-16] {Jump up to: 16.0} ^16.1 ^16.2 "Connections, Clients, and Servers". RFC 9110, HTTP Semantics. sec. 3.3. doi:10.17487/RFC9110. RFC 9110.

[rfc1945-1.3-17] "Overall Operation". RFC 1945. pp. 6–8. sec. 1.3. doi:10.17487/RFC1945. RFC 1945.

[rfc9112-9.1-18] {Jump up to: 18.0} ^18.1 ^18.2 "Connection Management: Establishment". RFC 9112, HTTP/1.1. sec. 9.1. doi:10.17487/RFC9112. RFC 9112.

[rfc9112-9.3-19] "Connection Management: Persistence". RFC 9112, HTTP/1.1. sec. 9.3. doi:10.17487/RFC9112. RFC 9112.

[20] "Classic HTTP Documents". W3.org. 1998-05-14. Retrieved 2010-08-01.

[rfc9113-2-22] "HTTP/2 Protocol Overview". RFC 9113, HTTP/2). sec. 2. doi:10.17487/RFC7540. RFC 7540.

[23] "Invention Of The Web, Web History, Who Invented the Web, Tim Berners-Lee, Robert Cailliau, CERN, First Web Server". LivingInternet (in English). Retrieved 2021-08-11.

[24] Berners-Lee, Tim (1990-10-02). "daemon.c - TCP/IP based server for HyperText". www.w3.org. Retrieved 2021-08-11.

[25] Berners-Lee, Tim. "HyperText Transfer Protocol". World Wide Web Consortium. Retrieved 31 August 2010.

[HTTP/0.9-specifications-26] {Jump up to: 25.0} ^25.1 ^25.2 Cite error: Invalid <ref> tag; no text was provided for refs named HTTP/0.9-specifications

[raggettprofile-27] Raggett, Dave. "Dave Raggett's Bio". World Wide Web Consortium. Retrieved 11 June 2010.

[28] Raggett, Dave; Berners-Lee, Tim. "Hypertext Transfer Protocol Working Group". World Wide Web Consortium. Retrieved 29 September 2010.

[29] Raggett, Dave. "HTTP WG Plans". World Wide Web Consortium. Retrieved 29 September 2010.

[HTTP-Persistent-Connections-30] {Jump up to: 29.0} ^29.1 David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections") (in English). O'Reilly Media, inc. ISBN 9781565925090. Retrieved 2021-10-18.

[31] "HTTP/1.1". Webcom.com Glossary entry. Archived from the original on 2001-11-21. Retrieved 2009-05-29.

[HTTP-NG-Working-Group-32] "HTTP-NG Working Group". www.w3.org (in English). World Wide Web Consortium. 1997. Retrieved 2021-10-19.

[HTTP-WG-2-33] Web Administrator (2007). "HTTP Working Group". httpwg.org (in English). IETF. Retrieved 2021-10-19.

[HTTP-WG-httpbis-34] Web Administrator (2007). "HTTP Working Group: charter httpbis". datatracker.ietf.org (in English). IETF. Retrieved 2021-10-19.

[SPDY-vs-HTTP/1.1-35] "एसपीडीवाई: तेज़ वेब के लिए एक प्रयोगात्मक प्रोटोकॉल". dev.chromium.org (in English). Google. 2009-11-01. Retrieved 2021-10-19.

[HTTPbis-rechartering-act-36] IESG Secretary (2012-03-19). "WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)" (in English). IETF; HTTP WG. Retrieved 2021-10-19.

[HTTP/2-introduction-37] Ilya Grigorik; Surma (2019-09-03). "उच्च निष्पादन ब्राउज़र नेटवर्किंग: HTTP/2 का परिचय". developers.google.com (in English). Google Inc. Retrieved 2021-10-19.

[HTTP/0.9-chrome-38] Matt Menke (2016-06-30). "बहिष्कृत करने और निकालने का इरादा: HTTP/0.9 समर्थन". groups.google.com (in English). Retrieved 2021-10-15.

[40] "HTTP/3" (in English). Retrieved 2022-06-06.

[rfc9110-4.2.1-41] "http URI Scheme". RFC 9110, HTTP Semantics. sec. 4.2.1. doi:10.17487/RFC9110. RFC 9110.

[rfc9110-4.2.2-42] "https URI Scheme". RFC 9110, HTTP Semantics. sec. 4.2.2. doi:10.17487/RFC9110. RFC 9110.

[44] Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019-01-25). "Secure and efficient protection for HTTP cookies with self-verification". International Journal of Communication Systems (in English). 32 (2): e3857. doi:10.1002/dac.3857. S2CID 59524143.

[rfc9112-2.1-46] {Jump up to: 42.0} ^42.1 "Message format". RFC 9112: HTTP/1.1. sec. 2.1. doi:10.17487/RFC9112. RFC 9112.

[apacheweek_com-http11-47] "अपाचे वीक। एचटीटीपी/1.1". 090502 apacheweek.com

[rfc1945-8-48] Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. "Method Definitions". Hypertext Transfer Protocol – HTTP/1.0. IETF. pp. 30–32. sec. 8. doi:10.17487/RFC1945. RFC 1945.

[rfc2616-9-49] "Method Definitions". RFC 2616. pp. 51–57. sec. 9. doi:10.17487/RFC2616. RFC 2616.

[rfc9112-3-50] "Request Line". RFC 9112, HTTP/1.1. sec. 3. doi:10.17487/RFC9112. RFC 9112.

[rfc9110-9.1-51] {Jump up to: 47.0} ^47.1 "Methods: Overview". RFC 9110, HTTP Semantics. sec. 9.1. doi:10.17487/RFC9110. RFC 9110.

[rfc9110-6.3-52] "Header Fields". RFC 9110, HTTP Semantics. sec. 6.3. doi:10.17487/RFC9110. RFC 9110.

[53] Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Technical Architecture Group finding. W3C. Retrieved 26 September 2010.

[rfc9110-9.3.3-54] "POST". RFC 9110, HTTP Semantics. sec. 9.3.3. doi:10.17487/RFC9110. RFC 9110.

[rfc9110-9.3.4-55] "PUT". RFC 9110, HTTP Semantics. sec. 9.3.4. doi:10.17487/RFC9110. RFC 9110.

[rfc9110-9.3.6-56] "CONNECT". RFC 9110, HTTP Semantics. sec. 9.3.6. doi:10.17487/RFC9110. RFC 9110.

[HTTP-proxy-arbitrary-TCP-57] "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. Retrieved 2007-05-10.

[rfc5789-58] Dusseault, Lisa; Snell, James M. (March 2010). PATCH Method for HTTP. IETF. doi:10.17487/RFC5789. RFC 5789.

[oreilly-get-rails-59] {Jump up to: 55.0} ^55.1 Ediger, Brad (2007-12-21). Advanced Rails: Building Industrial-Strength Web Apps in Record Time. O'Reilly Media, Inc. p. 188. ISBN 978-0596519728. A common mistake is to use GET for an action that updates a resource. [...] This problem came into the Rails public eye in 2005, when the Google Web Accelerator was released.

[60] Cantrell, Christian (2005-06-01). "What Have We Learned From the Google Web Accelerator?". Adobe Blogs. Adobe. Archived from the original on 2017-08-19. Retrieved 2018-11-19.

[63] Luotonen, Ari; Franks, John (February 22, 1996). Byte Range Retrieval Extension to HTTP. IETF. I-D draft-ietf-http-range-retrieval-00.

[64] Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83. ISBN 9781580531764.

[65] Zalewski, Michal. "Browser Security Handbook". Retrieved 30 April 2015.

[66] "Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1". Retrieved 30 April 2015.

[67] "Mozilla Bug 276813 – [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1". Retrieved 30 April 2015.

[rfc5988-68] Nottingham, Mark (October 2010). Web Linking. IETF. doi:10.17487/RFC5988. RFC 5988.

[69] "Hypertext Transfer Protocol Bis (httpbis) – Charter". IETF. 2012.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[note 1]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[note 2]

[38]

[39]

[40]

[note 3]

[41]

[note 4]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[note 5]

[note 6]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

Expand v t e Uniform Resource Identifier (URI) schemes
Official	about acct crid data file ftp geo gopher http https info ldap mailto nfs nntp sip / sips tag telnet urn view-source ws / wss xmpp
Unofficial	coffee ed2k gemini feed finger irc / irc6 / ircs ldaps magnet rsync ymsgr
Protocol list


International standard	RFC 1945 HTTP/1.0 RFC 9110 HTTP Semantics RFC 9111 HTTP Caching RFC 9112 HTTP/1.1 RFC 9113 HTTP/2 RFC 7541 HTTP/2: HPACK Header Compression RFC 8164 HTTP/2: Opportunistic Security for HTTP/2 RFC 8336 HTTP/2: The ORIGIN HTTP/2 Frame RFC 8441 HTTP/2: Bootstrapping WebSockets with HTTP/2 RFC 9114 HTTP/3 RFC 9204 HTTP/3: QPACK: Field Compression
Developed by	initially CERN; IETF, W3C
Introduced	1991; 34 years ago (1991)

Anonymous

Search