Difference between revisions of "एचटीटीपी"

एचटीटीपी
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; 33 years ago

Latest revision as of 19:52, 9 September 2023

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

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

एचटीटीपी प्रोटोकॉल का वह प्रथम वर्जन शीघ्र ही अधिक विस्तृत वर्जन में विकसित हुआ जो कि भविष्य के वर्जन 1.0 की ओर प्रथम उपाय था।^[3]

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

एचटीटीपी/1 को 1996 में अंतिम रूप दिया गया और प्रत्येक प्रकार से (वर्जन 1.0 के रूप में) डॉक्युमेंटेड किया गया था।

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

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

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

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

प्रौद्योगिकी अवलोकन

File:Internet1.svg

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

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

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

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

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

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

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

एचटीटीपी/1.0 में प्रत्येक संसाधन रिक्वेस्ट के लिए सर्वर से भिन्न कनेक्शन बनाया जाता है।^[19]

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

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

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

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

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

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

इतिहास

टिम बर्नर्स-ली

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

प्रथम वेब सर्वर 1990 में प्रसारित हुआ।^[24]^[25] उपयोग किए गए प्रोटोकॉल में केवल एक विधि थी, अर्थात् जीईटी, जो सर्वर से पृष्ठ का रिक्वेस्ट करेगी।^[26] सर्वर से रेस्पोंस सदैव एचटीएमएल पृष्ठ होती थी। ^[2]

एचटीटीपी माइलस्टोन वर्जन का सारांश

वर्जन	वर्ष प्रस्तुत किया	वर्तमान स्टेटस
एचटीटीपी/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 केवल जीईटी विधि का समर्थन करता है, क्लाइंट को सर्वर से केवल एचटीएमएल डाक्यूमेंट प्राप्त करने की अनुमति देता है, किन्तु किसी अन्य फ़ाइल स्वरूपों या इनफार्मेशन अपलोड का समर्थन नहीं करता है।^[2]

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

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

डब्ल्यू3सी एचटीटीपी वर्किंग ग्रुप

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

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

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

एचटीटीपी/1.0

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

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

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

एचटीटीपी/2

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

एचटीटीपी का नया वर्जन विकसित करने के लिए क्या करना है, इसके विषय में कुछ महीनों के पश्चात, इसे स्पीडी (SPDY) से प्राप्त करने का निर्णय लिया गया।^[38]

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

2014 एचटीटीपी/1.1 के लिए अपडेट

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

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

एचटीटीपी/0.9 डेप्रेसशन

RFC 7230 परिशिष्ट-A में, एचटीटीपी/0.9 को एचटीटीपी/1.1 वर्जन (और उच्चतर) का समर्थन करने वाले सर्वरों के लिए बहिष्कृत कर दिया गया था:^[39]

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

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

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

^{[note 2]}

एचटीटीपी/3

2020 में, प्रथम ड्राफ्ट एचटीटीपी/3 प्रकाशित किया गया और प्रमुख वेब ब्राउज़र और वेब सर्वर ने इसे अपनाना प्रारंभ कर दिया।

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

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

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

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

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

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

कनेक्शन के माध्यम से रिक्वेस्ट और रेस्पोंस मेसेज

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

परसिस्टेंट कनेक्शन

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

एचटीटीपी/1.0 में, जैसा कि RFC 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]

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

ऑथेंटिकेशन रियलएमएस

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

एचटीटीपी एप्लीकेशन सेशन

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

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

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

एचटीटीपी/1.1 रिक्वेस्ट मेसेज

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

रिक्वेस्ट सिंटैक्स

क्लाइंट सर्वर को रिक्वेस्ट मेसेज भेजता है, जिसमें निम्न सम्मिलित हैं:^[45]

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

GET /images/logo.png HTTP/1.1

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

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

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

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

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

रिक्वेस्ट की विधि

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

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

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

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

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

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

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

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

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

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

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

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

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

रिक्वेस्ट विधियों के गुण
रिक्वेस्ट विधि	आरएफसी	रिक्वेस्ट में पेलोड बॉडी है	रेस्पोंस में पेलोड बॉडी है	सेफ	निर्बल	संचित करने योग्य
गेट	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 जैसे किसी यूआरएल के माध्यम से किसी संसाधन को विस्थापित करने की अनुमति दे सकती है, जो इच्छानुसार प्रकार से प्राप्त किया जाता है, यहां तक कि जीईटी का उपयोग करते हुए भी, लेख को सरलता से विस्थापित कर देगा।^[58] उत्तम प्रकार से कोडित वेबसाइट को इस क्रिया के लिए डिलीट या पोस्ट विधि की आवश्यकता होगी, जो अन्य-दुर्भावनापूर्ण बॉट्स नहीं करेंगे।

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

इदम्पोटेंट विधि

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

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

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

कैचएबल विधि

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

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

हेडर फ़ील्ड का रिक्वेस्ट करें

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

एचटीटीपी/1.1 रेस्पोंस मेसेज

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

रेस्पोंस सिंटैक्स

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

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

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 में यह अनिवार्य है। (A "/" (स्लैश) सामान्यतः वेबसर्वर डायरेक्टरी इंडेक्स/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>

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

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

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

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

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

सिमिलर प्रोटोकॉल

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

यह भी देखें

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

↑ 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.^[30]
↑ ^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.

संदर्भ

↑ ^1.0 ^1.1 ^1.2 ^1.3 Fielding, R.; Nottingham, M.; Reschke, J. (June 2022). HTTP शब्दार्थ. IETF. doi:10.17487/RFC9110. RFC 9110.
↑ ^2.0 ^2.1 ^2.2 ^2.3 Tim Berner-Lee (1991-01-01). "The Original HTTP as defined in 1991". www.w3.org. World Wide Web Consortium. Retrieved 2010-07-24.
↑ ^3.0 ^3.1 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org. World Wide Web Consortium. Retrieved 2021-10-19.
↑ में RFC 1945. उस विनिर्देशन को तब एचटीटीपी/1.1 द्वारा समाप्त कर दिया गया था।
↑ "वेबसाइटों के लिए डिफ़ॉल्ट प्रोटोकॉल https के उपयोग के आंकड़े". 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.
↑ "ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) एप्लीकेशन-लेयर प्रोटोकॉल नेगोशिएशन एक्सटेंशन". 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. Retrieved 2020-06-02. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.
↑ "HTTP/3". 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. 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. Retrieved 2022-07-01.
↑ ^18.0 ^18.1 ^18.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.
↑ ^20.0 ^20.1 ^20.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.
↑ "क्लासिक HTTP दस्तावेज़". 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.
↑ "वेब का आविष्कार, वेब इतिहास, वेब का आविष्कार किसने किया, टिम बर्नर्स-ली, रॉबर्ट कैलियाउ, सर्न, पहला वेब सर्वर". LivingInternet. 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. "हाइपरटेक्स्ट परहस्त शिष्टाचार". World Wide Web Consortium. Retrieved 31 August 2010.
↑ Raggett, Dave. "डेव रैगेट का बायो". World Wide Web Consortium. Retrieved 11 June 2010.
↑ Raggett, Dave; Berners-Lee, Tim. "हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल वर्किंग ग्रुप". World Wide Web Consortium. Retrieved 29 September 2010.
↑ Raggett, Dave. "HTTP डब्ल्यूजी योजनाएं". World Wide Web Consortium. Retrieved 29 September 2010.
↑ ^30.0 ^30.1 David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections"). 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.
↑ "एचटीटीपी-एनजी वर्किंग ग्रुप". www.w3.org. World Wide Web Consortium. 1997. Retrieved 2021-10-19.
↑ Web Administrator (2007). "HTTP वर्किंग ग्रुप". httpwg.org. IETF. Retrieved 2021-10-19.
↑ Web Administrator (2007). "HTTP Working Group: charter httpbis". datatracker.ietf.org. IETF. Retrieved 2021-10-19.
↑ "एसपीडीवाई: तेज़ वेब के लिए एक प्रयोगात्मक प्रोटोकॉल". dev.chromium.org. Google. 2009-11-01. Retrieved 2021-10-19.
↑ "httpbis को रिचार्ज करना". IETF; HTTP WG. 2012-01-24. Retrieved 2021-10-19.
↑ IESG Secretary (2012-03-19). "WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)". IETF; HTTP WG. Retrieved 2021-10-19.
↑ Ilya Grigorik; Surma (2019-09-03). "उच्च निष्पादन ब्राउज़र नेटवर्किंग: HTTP/2 का परिचय". developers.google.com. Google Inc. Retrieved 2021-10-19.
↑ "Appendix-A: HTTP Version History". RFC 7230, HTTP/1.1: Message Syntax and Routing. p. 78. sec. A. doi:10.17487/RFC7230. RFC 7230.
↑ Matt Menke (2016-06-30). "बहिष्कृत करने और निकालने का इरादा: HTTP/0.9 समर्थन". groups.google.com. Retrieved 2021-10-15.
↑ "HTTP/3". 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). "स्व-सत्यापन के साथ HTTP कुकीज़ के लिए सुरक्षित और कुशल सुरक्षा". International Journal of Communication Systems. 32 (2): e3857. doi:10.1002/dac.3857. S2CID 59524143.
↑ ^45.0 ^45.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.
↑ ^50.0 ^50.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). "यूआरआई, एड्रेसेबिलिटी, और एचटीटीपी जीईटी और पोस्ट का उपयोग". 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). HTTP के लिए पैच विधि. IETF. doi:10.17487/RFC5789. RFC 5789.
↑ ^58.0 ^58.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). HTTP के लिए बाइट रेंज रिट्रीवल एक्सटेंशन. IETF. I-D draft-ietf-http-range-retrieval-00.
↑ Canavan, John (2001). नेटवर्किंग सुरक्षा के मूल तत्व. Norwood, MA: Artech House. pp. 82–83. ISBN 9781580531764.
↑ Zalewski, Michal. "ब्राउज़र सुरक्षा पुस्तिका". 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). वेब लिंकिंग. IETF. doi:10.17487/RFC5988. RFC 5988.
↑ "Hypertext Transfer Protocol Bis (httpbis) – Charter". IETF. 2012.

बाहरी संबंध

"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.

[23] 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.

[42] 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.

[46] 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.^[30]

[http-23-message-48] 4.0 ^4.1 HTTP/2 and HTTP/3 have a different representation for HTTP methods and headers.

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

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

[rfc9110-1] 1.0 ^1.1 ^1.2 ^1.3 Fielding, R.; Nottingham, M.; Reschke, J. (June 2022). HTTP शब्दार्थ. IETF. doi:10.17487/RFC9110. RFC 9110.

[HTTP.2F0.9-specifications-2] 2.0 ^2.1 ^2.2 ^2.3 Tim Berner-Lee (1991-01-01). "The Original HTTP as defined in 1991". www.w3.org. World Wide Web Consortium. Retrieved 2010-07-24.

[HTTP.2F1.0-first-unofficial-draft-3] 3.0 ^3.1 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org. World Wide Web Consortium. Retrieved 2021-10-19.

[4] में RFC 1945. उस विनिर्देशन को तब एचटीटीपी/1.1 द्वारा समाप्त कर दिया गया था।

[HTTPS-usage-web-servers-5] "वेबसाइटों के लिए डिफ़ॉल्ट प्रोटोकॉल https के उपयोग के आंकड़े". w3techs.com. Retrieved 2022-10-16.

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

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

[rfc7301-8] "ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) एप्लीकेशन-लेयर प्रोटोकॉल नेगोशिएशन एक्सटेंशन". IETF. July 2014. RFC 7301.

[9] 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.

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

[11] "HTTP/3". Retrieved 2022-06-06.

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

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

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

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

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

[17] "HTTP/3 is Fast". Request Metrics. Retrieved 2022-07-01.

[rfc9110-3.3-18] 18.0 ^18.1 ^18.2 "Connections, Clients, and Servers". RFC 9110, HTTP Semantics. sec. 3.3. doi:10.17487/RFC9110. RFC 9110.

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

[rfc9112-9.1-20] 20.0 ^20.1 ^20.2 "Connection Management: Establishment". RFC 9112, HTTP/1.1. sec. 9.1. doi:10.17487/RFC9112. RFC 9112.

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

[22] "क्लासिक HTTP दस्तावेज़". W3.org. 1998-05-14. Retrieved 2010-08-01.

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

[25] "वेब का आविष्कार, वेब इतिहास, वेब का आविष्कार किसने किया, टिम बर्नर्स-ली, रॉबर्ट कैलियाउ, सर्न, पहला वेब सर्वर". LivingInternet. Retrieved 2021-08-11.

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

[27] Berners-Lee, Tim. "हाइपरटेक्स्ट परहस्त शिष्टाचार". World Wide Web Consortium. Retrieved 31 August 2010.

[raggettprofile-28] Raggett, Dave. "डेव रैगेट का बायो". World Wide Web Consortium. Retrieved 11 June 2010.

[29] Raggett, Dave; Berners-Lee, Tim. "हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल वर्किंग ग्रुप". World Wide Web Consortium. Retrieved 29 September 2010.

[30] Raggett, Dave. "HTTP डब्ल्यूजी योजनाएं". World Wide Web Consortium. Retrieved 29 September 2010.

[HTTP-Persistent-Connections-31] 30.0 ^30.1 David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections"). O'Reilly Media, inc. ISBN 9781565925090. Retrieved 2021-10-18.

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

[HTTP-NG-Working-Group-33] "एचटीटीपी-एनजी वर्किंग ग्रुप". www.w3.org. World Wide Web Consortium. 1997. Retrieved 2021-10-19.

[HTTP-WG-2-34] Web Administrator (2007). "HTTP वर्किंग ग्रुप". httpwg.org. IETF. Retrieved 2021-10-19.

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

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

[37] "httpbis को रिचार्ज करना". IETF; HTTP WG. 2012-01-24. Retrieved 2021-10-19.

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

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

[rfc7230-Appendix-A-40] "Appendix-A: HTTP Version History". RFC 7230, HTTP/1.1: Message Syntax and Routing. p. 78. sec. A. doi:10.17487/RFC7230. RFC 7230.

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

[43] "HTTP/3". Retrieved 2022-06-06.

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

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

[47] Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019-01-25). "स्व-सत्यापन के साथ HTTP कुकीज़ के लिए सुरक्षित और कुशल सुरक्षा". International Journal of Communication Systems. 32 (2): e3857. doi:10.1002/dac.3857. S2CID 59524143.

[rfc9112-2.1-49] 45.0 ^45.1 "Message format". RFC 9112: HTTP/1.1. sec. 2.1. doi:10.17487/RFC9112. RFC 9112.

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

[rfc1945-8-51] 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-52] "Method Definitions". RFC 2616. pp. 51–57. sec. 9. doi:10.17487/RFC2616. RFC 2616.

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

[rfc9110-9.1-54] 50.0 ^50.1 "Methods: Overview". RFC 9110, HTTP Semantics. sec. 9.1. doi:10.17487/RFC9110. RFC 9110.

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

[56] Jacobs, Ian (2004). "यूआरआई, एड्रेसेबिलिटी, और एचटीटीपी जीईटी और पोस्ट का उपयोग". Technical Architecture Group finding. W3C. Retrieved 26 September 2010.

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

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

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

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

[rfc5789-61] Dusseault, Lisa; Snell, James M. (March 2010). HTTP के लिए पैच विधि. IETF. doi:10.17487/RFC5789. RFC 5789.

[oreilly-get-rails-62] 58.0 ^58.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.

[63] 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.

[66] Luotonen, Ari; Franks, John (February 22, 1996). HTTP के लिए बाइट रेंज रिट्रीवल एक्सटेंशन. IETF. I-D draft-ietf-http-range-retrieval-00.

[67] Canavan, John (2001). नेटवर्किंग सुरक्षा के मूल तत्व. Norwood, MA: Artech House. pp. 82–83. ISBN 9781580531764.

[68] Zalewski, Michal. "ब्राउज़र सुरक्षा पुस्तिका". Retrieved 30 April 2015.

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

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

[rfc5988-71] Nottingham, Mark (October 2010). वेब लिंकिंग. IETF. doi:10.17487/RFC5988. RFC 5988.

[72] "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]

[21]

[22]

[note 1]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[note 2]

[41]

[42]

[43]

[note 3]

[44]

[note 4]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[note 5]

[note 6]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

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