एचटीटीपी: Difference between revisions

एचटीटीपी
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 15:34, 27 October 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 (in English). World Wide Web Consortium. Retrieved 2010-07-24.
↑ ^3.0 ^3.1 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org (in English). 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 (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.
↑ ^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 (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. "हाइपरटेक्स्ट परहस्त शिष्टाचार". 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") (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.
↑ "एचटीटीपी-एनजी वर्किंग ग्रुप". www.w3.org (in English). World Wide Web Consortium. 1997. Retrieved 2021-10-19.
↑ Web Administrator (2007). "HTTP वर्किंग ग्रुप". 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.
↑ "httpbis को रिचार्ज करना" (in English). IETF; HTTP WG. 2012-01-24. 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.
↑ "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 (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). "स्व-सत्यापन के साथ HTTP कुकीज़ के लिए सुरक्षित और कुशल सुरक्षा". International Journal of Communication Systems (in English). 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/0.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 (in English). World Wide Web Consortium. Retrieved 2010-07-24.

[HTTP/1.0-first-unofficial-draft-3] 3.0 ^3.1 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org (in English). 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 (in English). Retrieved 2020-06-02. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.

[11] "HTTP/3" (in English). 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 (in English). 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 (in English). 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 (in English). 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") (in English). 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 (in English). World Wide Web Consortium. 1997. Retrieved 2021-10-19.

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

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

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

[37] "httpbis को रिचार्ज करना" (in English). 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)" (in English). IETF; HTTP WG. Retrieved 2021-10-19.

[HTTP/2-introduction-39] Ilya Grigorik; Surma (2019-09-03). "उच्च निष्पादन ब्राउज़र नेटवर्किंग: HTTP/2 का परिचय". developers.google.com (in English). 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/0.9-chrome-41] Matt Menke (2016-06-30). "बहिष्कृत करने और निकालने का इरादा: HTTP/0.9 समर्थन". groups.google.com (in English). Retrieved 2021-10-15.

[43] "HTTP/3" (in English). 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 (in English). 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]

@@ Line 23: / Line 23: @@
 {{IPstack}}
-हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (एचटीटीपी) वितरित, सहयोगी, [[हाइपरमीडिया]] सूचना प्रणाली के लिए [[इंटरनेट प्रोटोकॉल सूट]] मॉडल में [[अनुप्रयोग परत]] प्रोटोकॉल है।<ref name="rfc9110" />एचटीटीपी वर्ल्ड वाइड वेब के लिए डेटा संचार का मूल है, जहां [[हाइपरटेक्स्ट]] दस्तावेज़ों में अन्य संसाधनों के [[हाइपरलिंक|हाइपरलिंक्स]] सम्मिलित होते हैं जिन्हें उपयोगकर्ता  सरलता से एक्सेस कर सकता है, उदाहरण के लिए [[कम्प्यूटर का माउस]] क्लिक या वेब ब्राउज़र में स्क्रीन टैप करके किया जाता है।
+'''हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (एचटीटीपी)''' वितरित, सहयोगी, [[हाइपरमीडिया]] सूचना प्रणाली के लिए [[इंटरनेट प्रोटोकॉल सूट]] मॉडल में [[अनुप्रयोग परत]] प्रोटोकॉल है।<ref name="rfc9110" />एचटीटीपी वर्ल्ड वाइड वेब के लिए डेटा संचार का मूल है, जहां [[हाइपरटेक्स्ट]] दस्तावेज़ों में अन्य संसाधनों के [[हाइपरलिंक|हाइपरलिंक्स]] सम्मिलित होते हैं जिन्हें उपयोगकर्ता  सरलता से एक्सेस कर सकता है, उदाहरण के लिए [[कम्प्यूटर का माउस]] क्लिक या वेब ब्राउज़र में स्क्रीन टैप करके किया जाता है।
-एचटीटीपी का विकास 1989 में [[सर्न]] में [[ टिक बैरनर्स - ली |टिक बर्नर्स-ली]] द्वारा प्रारंभ किया गया था और क्लाइंट के व्यवहार का वर्णन करने वाले साधारण दस्तावेज़ में सारांशित किया गया था और पूर्व एचटीटीपी प्रोटोकॉल संस्करण का उपयोग करने वाले सर्वर को 0.9 नाम दिया गया था।<ref>{{Cite web|url=https://www.w3.org/pub/WWW/Protocols/HTTP/AsImplemented.html|title=1991 में परिभाषित मूल HTTP|website=www.w3.org|publisher=World Wide Web Consortium|date=1991-01-01|access-date=2010-07-24|language=en|author=Tim Berner-Lee}}</ref>
+एचटीटीपी का विकास 1989 में [[सर्न]] में [[ टिक बैरनर्स - ली |टिक बर्नर्स-ली]] द्वारा प्रारंभ किया गया था और क्लाइंट के व्यवहार का वर्णन करने वाले साधारण दस्तावेज़ में सारांशित किया गया था और पूर्व एचटीटीपी प्रोटोकॉल संस्करण का उपयोग करने वाले सर्वर को 0.9 नाम दिया गया था<ref name="HTTP/0.9-specifications">{{Cite web|url=https://www.w3.org/pub/WWW/Protocols/HTTP/AsImplemented.html|title=The Original HTTP as defined in 1991|website=www.w3.org|publisher=World Wide Web Consortium|date=1991-01-01|access-date=2010-07-24|language=en|author=Tim Berner-Lee}}</ref>
 एचटीटीपी प्रोटोकॉल का वह प्रथम संस्करण शीघ्र ही अधिक विस्तृत संस्करण में विकसित हुआ जो कि भविष्य के संस्करण 1.0 की ओर प्रथम उपाय था।<ref name= HTTP/1.0-first-unofficial-draft>{{Cite web|url=https://www.w3.org/Protocols/HTTP/HTTP2.html|title=1992 में परिभाषित मूल HTTP|website=www.w3.org|publisher=World Wide Web Consortium|year=1992|access-date=2021-10-19|language=en|author=Tim Berner-Lee}}</ref>
@@ Line 33: / Line 33: @@
 एचटीटीपी/1 को 1996 में अंतिम रूप दिया गया और प्रत्येक प्रकार से (संस्करण 1.0 के रूप में) प्रलेखित किया गया।
-रेफरी> में {{IETF RFC|1945}}. उस विनिर्देशन को तब एचटीटीपी/1.1 द्वारा समाप्त कर दिया गया था। <nowiki></ref></nowiki> यह 1997 में (संस्करण 1.1 के रूप में) विकसित हुआ और फिर इसके विनिर्देशों को 1999, 2014 और 2022 में अद्यतन किया गया। रेफरी>{{IETF RFC|2068}} (1997) अप्रचलित था {{IETF RFC|2616}} 1999 में, जिसे अप्रचलित कर दिया गया था {{IETF RFC|7230}} 2014 में, जिसे अप्रचलित किया गया था {{IETF RFC|9110}} 2022 में।<nowiki></ref></nowiki>
+<ref> में {{IETF RFC|1945}}. उस विनिर्देशन को तब एचटीटीपी/1.1 द्वारा समाप्त कर दिया गया था। </ref> यह 1997 में (संस्करण 1.1 के रूप में) विकसित हुआ और फिर इसके विनिर्देशों को 1999, 2014 और 2022 में अद्यतन किया गया। रेफरी>{{IETF RFC|2068}} (1997) अप्रचलित था {{IETF RFC|2616}} 1999 में, जिसे अप्रचलित कर दिया गया था {{IETF RFC|7230}} 2014 में, जिसे अप्रचलित किया गया था {{IETF RFC|9110}} 2022 में।</ref>
 [[HTTPS|एचटीटीपी]] नाम का सुरक्षित संस्करण 80% से अधिक वेबसाइटों द्वारा उपयोग किया जाता है।<ref name="HTTPS-usage-web-servers">{{Cite web|title=वेबसाइटों के लिए डिफ़ॉल्ट प्रोटोकॉल https के उपयोग के आंकड़े|url=https://w3techs.com/technologies/details/ce-httpsdefault|access-date=2022-10-16|website=w3techs.com}}</ref>
@@ Line 71: / Line 71: @@
 [[File:Tim Berners-Lee CP 2.jpg|thumb|टिम बर्नर्स-ली]]हाइपरटेक्स्ट शब्द [[टेड नेल्सन]] द्वारा 1965 में ज़ानाडू परियोजना में लिखा गया था, जो [[वन्नेवर बुश]] के 1930 के दशक के माइक्रोफिल्म-आधारित सूचना पुनर्प्राप्ति और प्रबंधन "[[मेमेक्स|मेमेक्स"]]  प्रणाली से प्रेरित था, जिसे उनके 1945 के निबंध "ऐज़ वी मे थिंक" में वर्णित किया गया था। सर्न में टिम बर्नर्स-ली और उनकी टीम को एचटीएमएल और वेब सर्वर के लिए संबंधित प्रौद्योगिकी और वेब ब्राउज़र नामक क्लाइंट [[ प्रयोक्ता इंटरफ़ेस |प्रयोक्ता इंटरफ़ेस]] के साथ मूल एचटीटीपी का आविष्कार करने का श्रेय दिया जाता है। बर्नर्स-ली ने अपने अन्य विचार: "वर्ल्डवाइडवेब" परियोजना को अपनाने में सहायता करने के लिए एचटीटीपी को डिज़ाइन किया, जिसे प्रथम बार 1989 में प्रस्तावित किया गया था, जिसे अब वर्ल्ड वाइड वेब के रूप में जाना जाता है।
-[[CERN httpd|प्रथम वेब सर्वर]] 1990 में प्रसारित हुआ।<ref>{{Cite web |title=वेब का आविष्कार, वेब इतिहास, वेब का आविष्कार किसने किया, टिम बर्नर्स-ली, रॉबर्ट कैलियाउ, सर्न, पहला वेब सर्वर|url=https://www.livinginternet.com/w/wi_lee.htm |access-date=2021-08-11 |website=LivingInternet |language=en-US}}</ref><ref>{{Cite web |last=Berners-Lee| first=Tim| date=1990-10-02| title=daemon.c - TCP/IP based server for HyperText |url=https://www.w3.org/Daemon/old/V0.1/daemon.c |access-date=2021-08-11 |website=www.w3.org}}</ref> उपयोग किए गए प्रोटोकॉल में केवल एक विधि थी, अर्थात् जीईटी, जो सर्वर से पृष्ठ का अनुरोध करेगी।<ref>{{cite web |last=Berners-Lee |first=Tim |title=हाइपरटेक्स्ट परहस्त शिष्टाचार|url=https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Protocols/HTTP.html|publisher=[[World Wide Web Consortium]] |access-date=31 August 2010 }}</ref> सर्वर से प्रतिक्रिया सदैव एचटीएमएल पृष्ठ होती थी। <रेफरी नाम = HTTP/0.9-विनिर्देशन />
+[[CERN httpd|प्रथम वेब सर्वर]] 1990 में प्रसारित हुआ।<ref>{{Cite web |title=वेब का आविष्कार, वेब इतिहास, वेब का आविष्कार किसने किया, टिम बर्नर्स-ली, रॉबर्ट कैलियाउ, सर्न, पहला वेब सर्वर|url=https://www.livinginternet.com/w/wi_lee.htm |access-date=2021-08-11 |website=LivingInternet |language=en-US}}</ref><ref>{{Cite web |last=Berners-Lee| first=Tim| date=1990-10-02| title=daemon.c - TCP/IP based server for HyperText |url=https://www.w3.org/Daemon/old/V0.1/daemon.c |access-date=2021-08-11 |website=www.w3.org}}</ref> उपयोग किए गए प्रोटोकॉल में केवल एक विधि थी, अर्थात् जीईटी, जो सर्वर से पृष्ठ का अनुरोध करेगी।<ref>{{cite web |last=Berners-Lee |first=Tim |title=हाइपरटेक्स्ट परहस्त शिष्टाचार|url=https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Protocols/HTTP.html|publisher=[[World Wide Web Consortium]] |access-date=31 August 2010 }}</ref> सर्वर से प्रतिक्रिया सदैव एचटीएमएल पृष्ठ होती थी। <ref name="HTTP/0.9-specifications"/>
 === एचटीटीपी माइलस्टोन संस्करणों का सारांश ===
@@ Line 119: / Line 119: @@
 '''आईईटीएफ एचटीटीपी वर्किंग ग्रुप पुनः प्रारंभ हुआ'''
 : 2007 में, आईईटीएफ [https://httpwg.org/ एचटीटीपी वर्किंग ग्रुप] (एचटीटीपी डब्ल्यूजी बीआईएस या एचटीटीपीबीआईएस) को पूर्व प्राचीन एचटीटीपी/1.1 विनिर्देशों को संशोधित करने और स्पष्ट करने के लिए और दूसरा भविष्य के एचटीटीपी/2 विनिर्देशों को लिखने और परिष्कृत करने के लिए पुनः प्रारंभ किया गया था।<ref name="HTTP-WG-2">{{Cite web|url=https://httpwg.org/|title=HTTP वर्किंग ग्रुप|website=httpwg.org|publisher=IETF|year=2007|access-date=2021-10-19|language=en|author=Web Administrator}}</ref><ref name="HTTP-WG-httpbis">{{Cite web|url=https://datatracker.ietf.org/wg/httpbis/charter/|title=HTTP Working Group: charter httpbis|website=datatracker.ietf.org|publisher=IETF|year=2007|access-date=2021-10-19|language=en|author=Web Administrator}}</ref>
-;[[SPDY|स्पीडी (SPDY)]]<nowiki>:</nowiki> [[Google|गूगल]] द्वारा विकसित अनौपचारिक एचटीटीपी प्रोटोकॉल
+;[[SPDY|स्पीडी (SPDY)]][[Google|गूगल]] द्वारा विकसित अनौपचारिक एचटीटीपी प्रोटोकॉल
 : 2009 में, गूगल, निजी कंपनी, ने घोषणा की- कि उसने स्पीडी (SPDY) नामक नए एचटीटीपी बाइनरी प्रोटोकॉल का विकास और परीक्षण किया है। निहित उद्देश्य वेब ट्रैफ़िक को अधिक तीव्र करना था (विशेष रूप से भविष्य के वेब ब्राउज़र और उसके सर्वर के मध्य)।
 : एसपीडीवाई वास्तव में अनेक परीक्षणों में एचटीटीपी/1.1 की तुलना में अधिक तीव्र था और इसलिए इसे क्रोमियम (वेब ब्राउज़र) और फिर अन्य प्रमुख वेब ब्राउज़रों द्वारा शीघ्रता से अपनाया गया था।<ref name= SPDY-vs-HTTP/1.1>{{Cite web|url=http://dev.chromium.org/spdy/spdy-whitepaper|title=एसपीडीवाई: तेज़ वेब के लिए एक प्रयोगात्मक प्रोटोकॉल|website=dev.chromium.org|publisher=Google|date=2009-11-01|access-date=2021-10-19|language=en|author=}}</ref>
@@ Line 137: / Line 137: @@
 :* {{IETF RFC|7235}}, एचटीटीपी/1.1: प्रमाणीकरण
 ;एचटीटीपी/0.9 बहिष्करण
-:{{IETF RFC|7230}} परिशिष्ट-A में, एचटीटीपी/0.9 को एचटीटीपी/1.1 संस्करण (और उच्चतर) का समर्थन करने वाले सर्वरों के लिए बहिष्कृत कर दिया गया था:<ref name="rfc7230-Appendix-A">{{cite IETF |rfc=7230 |sectionname=Appendix-A: HTTP Version History|appendix=A |title=RFC 7230, HTTP/1.1: Message Syntax and Routing|page=78}}</ref>{{Blockquote |text=चूंकि एचटीटीपी/0.9 अनुरोध में हेडर फ़ील्ड का समर्थन नहीं करता है, इसके लिए नाम-आधारित वर्चुअल होस्ट (होस्ट हेडर फ़ील्ड के निरीक्षण द्वारा संसाधनों का चयन) का समर्थन करने के लिए कोई तंत्र नहीं है। '''कोई भी सर्वर जो नाम-आधारित वर्चुअल होस्ट प्रारम्भ करता है, उसे एचटीटीपी/0.9'' के लिए समर्थन अक्षम करना चाहिए। अधिकांश अनुरोध जो एचटीटीपी/0.9 प्रतीत होते हैं, वास्तव में, क्लाइंट द्वारा अनुरोध-लक्ष्य को ठीक से एन्कोड करने में विफल होने के कारण बुरी तरह से निर्मित एचटीटीपी/1.x अनुरोध हैं।
+:{{IETF RFC|7230}} परिशिष्ट-A में, एचटीटीपी/0.9 को एचटीटीपी/1.1 संस्करण (और उच्चतर) का समर्थन करने वाले सर्वरों के लिए बहिष्कृत कर दिया गया था:<ref name="rfc7230-Appendix-A">{{cite IETF |rfc=7230 |sectionname=Appendix-A: HTTP Version History|appendix=A |title=RFC 7230, HTTP/1.1: Message Syntax and Routing|page=78}}</ref>{{Blockquote |text=चूंकि एचटीटीपी/0.9 अनुरोध में हेडर फ़ील्ड का समर्थन नहीं करता है, इसके लिए नाम-आधारित वर्चुअल होस्ट (होस्ट हेडर फ़ील्ड के निरीक्षण द्वारा संसाधनों का चयन) का समर्थन करने के लिए कोई तंत्र नहीं है। '''कोई भी सर्वर जो नाम-आधारित वर्चुअल होस्ट प्रारम्भ करता है, उसे एचटीटीपी/0.9'' के लिए समर्थन अक्षम करना चाहिए। अधिकांश अनुरोध जो एचटीटीपी/0.9 प्रतीत होते हैं, वास्तव में, क्लाइंट द्वारा अनुरोध-लक्ष्य को ठीक से एन्कोड करने में विफल होने के कारण दुर्गति प्रकार से निर्मित एचटीटीपी/1.x अनुरोध हैं।
 |multiline=हाँ |style=फ़ॉन्ट-शैली: इटैलिक;}}
 : 2016 के पश्चात से अनेक उत्पाद प्रबंधकों और उपयोगकर्ता एजेंटों (ब्राउज़र, आदि) और वेब सर्वर के डेवलपर्स ने मुख्य रूप से निम्नलिखित कारणों से एचटीटीपी/0.9 प्रोटोकॉल के समर्थन को धीरे-धीरे अल्प करने और बहिष्कृत करने की योजना बनाना प्रारंभ कर दिया है:<ref name= HTTP/0.9-chrome -बहिष्कृत>{{Cite web|url=https://groups.google.com/a/chromium.org/g/blink-dev/c/OdKnpLlvVUo/m/1EpFGVUjAwAJ|title=बहिष्कृत करने और निकालने का इरादा: HTTP/0.9 समर्थन|website=groups.google.com|date=2016-06-30|access-date=2021-10-15|language=en|author=Matt Menke}}</ref>
@@ Line 157: / Line 157: @@
 :* {{IETF RFC|9218}}, एचटीटीपी के लिए एक्स्टेंसिबल प्रायोरिटी स्कीम
-== एचटीटीपी डेटा एक्सचेंज ==
+== एचटीटीपी डेटा परिवर्तन ==
 एचटीटीपी [[स्टेटलेस प्रोटोकॉल]] एप्लिकेशन-लेवल प्रोटोकॉल है और इसे क्लाइंट और सर्वर के मध्य डेटा के आदान-प्रदान के लिए विश्वसनीय नेटवर्क ट्रांसपोर्ट कनेक्शन की आवश्यकता होती है।<ref name="rfc9110-3.3">{{cite IETF |rfc=9110 |section=3.3 |sectionname=Connections, Clients, and Servers |title=RFC 9110, HTTP Semantics}}</ref> एचटीटीपी कार्यान्वयन में, ट्रांसमिशन कंट्रोल प्रोटोकॉल टीसीपी/आईपी कनेक्शन का उपयोग प्रसिद्ध [[टीसीपी और यूडीपी पोर्ट]] का उपयोग करके किया जाता है (सामान्यतः [[टीसीपी पोर्ट]] यदि कनेक्शन अनएन्क्रिप्टेड है या पोर्ट 443 यदि कनेक्शन एन्क्रिप्ट किया गया है, तो [[टीसीपी और यूडीपी पोर्ट नंबरों की सूची]] भी देखें)।<ref name="rfc9110-4.2.1">{{cite IETF |rfc=9110 |sectionname=http URI Scheme |section=4.2.1 |title=RFC 9110, HTTP Semantics}}</ref><ref name="rfc9110-4.2.2">{{cite IETF |rfc=9110 |sectionname=https URI Scheme |section=4.2.2 |title=RFC 9110, HTTP Semantics}}</ref> एचटीटीपी/2 में, टीसीपी/आईपी कनेक्शन और अनेक प्रोटोकॉल चैनल का उपयोग किया जाता है। एचटीटीपी/3 में, यूडीपी पर एप्लिकेशन ट्रांसपोर्ट प्रोटोकॉल क्विक का उपयोग किया जाता है।
 === कनेक्शन के माध्यम से अनुरोध और प्रतिक्रिया संदेश ===
-अनुरोध-प्रतिक्रिया संदेशों के अनुक्रम के माध्यम से डेटा का आदान-प्रदान किया जाता है, जो [[सत्र परत]] परिवहन कनेक्शन द्वारा आदान-प्रदान किया जाता है।<ref name="rfc9110-3.3" />एचटीटीपी क्लाइंट प्रारंभ में कनेक्शन (वास्तविक या वर्चुअल) स्थापित करने वाले सर्वर से कनेक्ट करने का प्रयास करता है। उस पोर्ट पर सुनने वाला एचटीटीपी(एस) सर्वर कनेक्शन स्वीकार करता है और पुनः क्लाइंट के अनुरोध संदेश की प्रतीक्षा करता है। क्लाइंट सर्वर को अपना अनुरोध भेजता है। अनुरोध प्राप्त होने पर, सर्वर एचटीटीपी प्रतिक्रिया संदेश वापस भेजता है (यदि आवश्यक हो तो हेडर प्लस बॉडी)। इस संदेश का मुख्य भाग सामान्यतः अनुरोधित संसाधन है, चूँकि त्रुटि संदेश या अन्य जानकारी भी लौटाई जा सकती है। किसी भी समय (अनेक कारणों से) क्लाइंट या सर्वर कनेक्शन बंद कर सकता है। सर्वर या क्लाइंट को भेजे गए अंतिम अनुरोध/प्रतिक्रिया संदेश में या अधिक एचटीटीपी हेडरों का उपयोग करके सामान्यतः कनेक्शन बंद करना अग्रिम रूप से विज्ञापित किया जाता है।<ref name="rfc9112-9.1">{{cite IETF |rfc=9112 |sectionname=Connection Management: Establishment |section=9.1 |title=RFC 9112, HTTP/1.1}}</ref>
+अनुरोध-प्रतिक्रिया संदेशों के अनुक्रम के माध्यम से डेटा का आदान-प्रदान किया जाता है, जो [[सत्र परत]] परिवहन कनेक्शन द्वारा आदान-प्रदान किया जाता है।<ref name="rfc9110-3.3" />एचटीटीपी क्लाइंट प्रारंभ में कनेक्शन (वास्तविक या वर्चुअल) स्थापित करने वाले सर्वर से कनेक्ट करने का प्रयास करता है। उस पोर्ट पर सुनने वाला एचटीटीपी(एस) सर्वर कनेक्शन स्वीकार करता है और पुनः क्लाइंट के अनुरोध संदेश की प्रतीक्षा करता है। क्लाइंट सर्वर को अपना अनुरोध भेजता है। अनुरोध प्राप्त होने पर, सर्वर एचटीटीपी प्रतिक्रिया संदेश वापस भेजता है। इस संदेश का मुख्य भाग सामान्यतः अनुरोधित संसाधन है, चूँकि त्रुटि संदेश या अन्य जानकारी भी लौटाई जा सकती है। किसी भी समय क्लाइंट या सर्वर कनेक्शन बंद कर सकता है। सर्वर या क्लाइंट को भेजे गए अंतिम अनुरोध/प्रतिक्रिया संदेश में या अधिक एचटीटीपी हेडरों का उपयोग करके सामान्यतः कनेक्शन बंद करना अग्रिम रूप से विज्ञापित किया जाता है।<ref name="rfc9112-9.1">{{cite IETF |rfc=9112 |sectionname=Connection Management: Establishment |section=9.1 |title=RFC 9112, HTTP/1.1}}</ref>
 === निरंतर कनेक्शन ===
 {{Main|एचटीटीपी निरंतर कनेक्शन}}
@@ Line 168: / Line 168: @@
 एचटीटीपी/1.0 में, जैसा कि RFC 1945 में कहा गया है, प्रतिक्रिया भेजे जाने के पश्चात टीसीपी/आईपी कनेक्शन को सदैव सर्वर द्वारा बंद कर दिया जाना चाहिए। {{refn|group=note|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.<ref name="HTTP-Persistent-Connections">{{Cite book|url=https://www.oreilly.com/library/view/http-the-definitive/1565925092/ch04s05.html|title=HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections")|author1=David Gourley|author2=Brian Totty|author3=Marjorie Sayer|author4=Anshu Aggarwal|author5=Sailu Reddy|language=en|publisher=O'Reilly Media, inc.|isbn=9781565925090|year=2002|access-date=2021-10-18}}</ref>}}
-एचटीटीपी/1.1 में कीप-अलाइव-मैकेनिज्म सामान्यतः प्रस्तुत किया गया था जिससे कि एक से अधिक अनुरोध/प्रतिक्रिया के लिए कनेक्शन का पुन: उपयोग किया जा सके। इस प्रकार के निरंतर कनेक्शन अनुरोध विलंबता (इंजीनियरिंग) को स्पष्ट रूप से अल्प कर देते हैं क्योंकि क्लाइंट को प्रथम अनुरोध भेजे जाने के पश्चात टीसीपी 3-वे-हैंडशेक कनेक्शन पर पुनः बातचीत करने की आवश्यकता नहीं होती है। और सकारात्मक पक्ष प्रभाव यह है कि, सामान्यतः, टीसीपी के स्लो-स्टार्ट-मैकेनिज्म के कारण कनेक्शन समय के साथ तीव्र हो जाता है।
+एचटीटीपी/1.1 में कीप-अलाइव-मैकेनिज्म सामान्यतः प्रस्तुत किया गया था जिससे कि एक से अधिक अनुरोध/प्रतिक्रिया के लिए कनेक्शन का पुन: उपयोग किया जा सके। इस प्रकार के निरंतर कनेक्शन अनुरोध विलंबता (इंजीनियरिंग) को स्पष्ट रूप से अल्प कर देते हैं क्योंकि क्लाइंट को प्रथम अनुरोध भेजे जाने के पश्चात टीसीपी 3-वे-हैंडशेक कनेक्शन पर पुनः वार्तालाप करने की आवश्यकता नहीं होती है। और सकारात्मक पक्ष प्रभाव यह है कि, सामान्यतः, टीसीपी के स्लो-स्टार्ट-मैकेनिज्म के कारण कनेक्शन समय के साथ तीव्र हो जाता है।
-एचटीटीपी/1.1 ने [[HTTP पाइपलाइनिंग|एचटीटीपी पाइपलाइनिंग]] को भी जोड़ा जिससे कि क्लाइंट को प्रत्येक प्रतिक्रिया की प्रतीक्षा करने से पूर्व अनेक अनुरोध भेजने की अनुमति देकर निरंतर कनेक्शन का उपयोग करते समय अंतराल को अल्प किया जा सके। इस अनुकूलन को कभी भी वास्तव में सुरक्षित नहीं माना गया क्योंकि कुछ वेब सर्वर और अनेक प्रॉक्सी सर्वर, विशेष रूप से क्लाइंट और सर्वर के मध्य इंटरनेट/[[इंट्रानेट]] में रखे गए पारदर्शी प्रॉक्सी सर्वर, पाइपलाइन किए गए अनुरोधों को उत्तम प्रकार से संभाल नहीं पाए (उन्होंने दूसरों को छोड़कर केवल प्रथम अनुरोध पूर्ण किया, उन्होंने बंद कर दिया कनेक्शन क्योंकि उन्होंने पूर्व अनुरोध के पश्चात अधिक डेटा देखा था या कुछ प्रॉक्सी ने प्रतिक्रियाओं को आदेश से बाहर कर दिया था)। इसके अतिरिक्त केवल हेड और कुछ जीईटी अनुरोध (अर्थात वास्तविक फ़ाइल अनुरोधों तक सीमित और कमांड के रूप में उपयोग किए जाने वाले क्वेरी स्ट्रिंग के बिना यूआरएल के साथ) को सुरक्षित विधियों और निष्क्रिय मोड विधियों में पाइपलाइन किया जा सकता है। पाइपलाइनिंग को सक्षम करके प्रारंभ की गई समस्याओं से अनेक वर्षों तक संघर्ष करने के पश्चात , एचटीटीपी/2 को अपनाने की घोषणा के कारण इस सुविधा को पूर्व अक्षम कर दिया गया और फिर अधिकांश ब्राउज़रों से भी विस्थापित कर दिया गया।
+एचटीटीपी/1.1 ने [[HTTP पाइपलाइनिंग|एचटीटीपी पाइपलाइनिंग]] को भी जोड़ा जिससे कि क्लाइंट को प्रत्येक प्रतिक्रिया की प्रतीक्षा करने से पूर्व अनेक अनुरोध भेजने की अनुमति देकर निरंतर कनेक्शन का उपयोग करते समय अंतराल को अल्प किया जा सके। इस अनुकूलन को कभी भी वास्तव में सुरक्षित नहीं माना गया क्योंकि कुछ वेब सर्वर और अनेक प्रॉक्सी सर्वर, विशेष रूप से क्लाइंट और सर्वर के मध्य इंटरनेट/[[इंट्रानेट]] में रखे गए पारदर्शी प्रॉक्सी सर्वर, पाइपलाइन किए गए अनुरोधों को उत्तम प्रकार से संभाल नहीं पाए (उन्होंने केवल प्रथम अनुरोध पूर्ण किया, उन्होंने बंद कर दिया कनेक्शन क्योंकि उन्होंने पूर्व अनुरोध के पश्चात अधिक डेटा देखा था या कुछ प्रॉक्सी ने प्रतिक्रियाओं को आदेश से बाहर कर दिया था)। इसके अतिरिक्त केवल हेड और कुछ जीईटी अनुरोध (अर्थात वास्तविक फ़ाइल अनुरोधों तक सीमित और कमांड के रूप में उपयोग किए जाने वाले क्वेरी स्ट्रिंग के बिना यूआरएल के साथ) को सुरक्षित विधियों और निष्क्रिय मोड विधियों में पाइपलाइन किया जा सकता है। पाइपलाइनिंग को सक्षम करके प्रारंभ की गई समस्याओं से अनेक वर्षों तक संघर्ष करने के पश्चात , एचटीटीपी/2 को अपनाने की घोषणा के कारण इस सुविधा को पूर्व अक्षम कर दिया गया और फिर अधिकांश ब्राउज़रों से भी विस्थापित कर दिया गया।
 एचटीटीपी/2 ने ही टीसीपी/आईपी कनेक्शन के माध्यम से अनेक समवर्ती अनुरोधों/प्रतिक्रियाओं को मल्टीप्लेक्स करके निरंतर कनेक्शन के उपयोग को बढ़ाया।
@@ Line 180: / Line 180: @@
 : अनुरोधित संसाधन सदैव प्रत्येक प्रकार से भेजा गया था।
 ; एचटीटीपी/1.0
-: जीईटी अनुरोधों को अनुमति देने के लिए क्लाइंट द्वारा कैश किए गए संसाधनों को प्रबंधित करने के लिए एचटीटीपी / 1.0 हेडर जोड़े गए; व्यवहार में सर्वर को अनुरोधित संसाधन की पूर्ण सामग्री को केवल तभी वापस करना होता है जब उसका अंतिम संशोधित समय क्लाइंट द्वारा ज्ञात नहीं होता है या यदि यह जीईटी अनुरोध के अंतिम पूर्ण प्रतिक्रिया के पश्चात परिवर्तित जाता है। इन हेडरों में से "सामग्री-एन्कोडिंग" को यह निर्दिष्ट करने के लिए जोड़ा गया था कि संसाधन की लौटाई गई सामग्री [[HTTP संपीड़न|एचटीटीपी संपीड़न]] थी या नहीं थी।
+: जीईटी अनुरोधों को अनुमति देने के लिए क्लाइंट द्वारा कैश किए गए संसाधनों को प्रबंधित करने के लिए एचटीटीपी/1.0 हेडर जोड़े गए; व्यवहार में सर्वर को अनुरोधित संसाधन की पूर्ण सामग्री को केवल तभी वापस करना होता है जब उसका अंतिम संशोधित समय क्लाइंट द्वारा ज्ञात नहीं होता है या यदि यह जीईटी अनुरोध के अंतिम पूर्ण प्रतिक्रिया के पश्चात परिवर्तित हो जाता है। इन हेडरों में से "सामग्री-एन्कोडिंग" को यह निर्दिष्ट करने के लिए जोड़ा गया था कि संसाधन की लौटाई गई सामग्री [[HTTP संपीड़न|एचटीटीपी]] थी या नहीं।
-: यदि किसी संसाधन की सामग्री की कुल लंबाई पूर्व में ज्ञात नहीं थी (अर्थात क्योंकि यह गतिशील रूप से उत्पन्न हुई थी, आदि) तो हेडर <code>"Content-Length: number"</code> एचटीटीपी हेडर में उपस्थित नहीं था और क्लाइंट ने माना कि जब सर्वर ने कनेक्शन बंद कर दिया, तो सामग्री प्रत्येक प्रकार से भेज दी गई थी। यह तंत्र संसाधन हस्तांतरण के मध्य सफलतापूर्वक पूर्ण और बाधित (एक सर्वर / नेटवर्क त्रुटि या कुछ और के कारण) के मध्य अंतर नहीं कर सका।
+: यदि किसी संसाधन की सामग्री की कुल लंबाई पूर्व में ज्ञात नहीं थी, तो हेडर <code>"Content-Length: number"</code> एचटीटीपी हेडर में उपस्थित नहीं था और क्लाइंट ने माना कि जब सर्वर ने कनेक्शन बंद कर दिया, तो सामग्री प्रत्येक प्रकार से भेज दी गई थी। यह तंत्र संसाधन हस्तांतरण के मध्य सफलतापूर्वक पूर्ण और बाधित (एक सर्वर / नेटवर्क त्रुटि या कुछ और के कारण) के मध्य अंतर नहीं कर सकता है।
 ; एचटीटीपी/1.1
 : एचटीटीपी/1.1 प्रस्तुत किया गया:
-:* कैश्ड संसाधनों की सशर्त पुनर्प्राप्ति को उत्तम प्रकार से प्रबंधित करने के लिए नए हेडर हैं।
+:* कैश्ड संसाधनों के अनुसार पुनर्प्राप्ति को उत्तम प्रकार से प्रबंधित करने के लिए नए हेडर हैं।
 :* खंडित स्थानांतरण एन्कोडिंग सामग्री को खण्डों में प्रवाहित करने की अनुमति देता है, जिससे की सर्वर को इसकी लंबाई पूर्व में ज्ञात न होने पर भी इसे विश्वसनीय रूप से भेजा जा सके (अर्थात क्योंकि यह गतिशील रूप से उत्पन्न होता है, आदि)।
-: * [[बाइट सर्विंग|बाइट रेंज सर्विंग]], जहां क्लाइंट संसाधन के केवल एक या एक से अधिक भागों (बाइट्स की रेंज) का अनुरोध कर सकता है (अर्थात प्रथम भाग, मध्य भाग या पूरी सामग्री के अंत में, आदि) और सर्वर सामान्यतः केवल अनुरोधित भाग भेजता है। यह बाधित डाउनलोड को पुनः प्रारंभ करने के लिए उपयोगी होता है (जब फ़ाइल वास्तव में बड़ी होती है), जब किसी सामग्री का केवल भाग दिखाना होता है या ब्राउज़र द्वारा पूर्व में ही दिखाई देने वाले भाग में गतिशील रूप से जोड़ा जाता है (अर्थात केवल प्रथमया निम्नलिखित एन टिप्पणियाँ) वेब पेज रिक्त समय, बैंडविड्थ और प्रणाली संसाधनों आदि के लिए है।
+: * [[बाइट सर्विंग|बाइट रेंज सर्विंग]], जहां क्लाइंट संसाधन को अधिक भागों (बाइट्स की रेंज) का अनुरोध कर सकता है (अर्थात प्रथम भाग, मध्य भाग या पूरी सामग्री के अंत में, आदि) और सर्वर सामान्यतः केवल अनुरोधित भाग भेजता है। यह बाधित डाउनलोड को पुनः प्रारंभ करने के लिए उपयोगी होता है (जब फ़ाइल वास्तव में बड़ी होती है), जब किसी सामग्री का केवल भाग दिखाना होता है या ब्राउज़र द्वारा पूर्व में ही दिखाई देने वाले भाग में गतिशील रूप से जोड़ा जाता है (अर्थात केवल प्रथमया निम्नलिखित एन टिप्पणियाँ) वेब पेज रिक्त समय, बैंडविड्थ और प्रणाली संसाधनों आदि के लिए है।
 ; एचटीटीपी/2, एचटीटीपी/3
-: एचटीटीपी/2 और एचटीटीपी/3 दोनों में एचटीटीपी/1.1 की उपरोक्त विशेषताएं रखी गई हैं।
+: एचटीटीपी/2 और एचटीटीपी/3 दोनों में एचटीटीपी/1.1 की उपरोक्त विशेषताएं हैं।
 == एचटीटीपी प्रमाणीकरण ==
-एचटीटीपी अनेक प्रमाणीकरण योजनाएँ प्रदान करता है जैसे कि [[बुनियादी पहुँच प्रमाणीकरण|मूलभूत एक्सेस प्रमाणीकरण]] और डाइजेस्ट एक्सेस प्रमाणीकरण जो चुनौती-प्रतिक्रिया तंत्र के माध्यम से संचालित होता है जिससे सर्वर अनुरोधित सामग्री की सेवा करने से पूर्व चुनौती की पहचान करता है और उसे प्रस्तावित करता है।
+एचटीटीपी अनेक प्रमाणीकरण योजनाएँ प्रदान करता है जैसे कि [[बुनियादी पहुँच प्रमाणीकरण|मूलभूत एक्सेस प्रमाणीकरण]] और डाइजेस्ट एक्सेस प्रमाणीकरण जो लक्षित-प्रतिक्रिया तंत्र के माध्यम से संचालित होता है जिससे सर्वर अनुरोधित सामग्री की सेवा करने से पूर्व लक्ष्य की पहचान करता है और उसे प्रस्तावित करता है।
-एचटीटीपी चुनौती-प्रतिक्रिया प्रमाणीकरण योजनाओं के विस्तृत सेट के माध्यम से अभिगम नियंत्रण और प्रमाणीकरण के लिए सामान्य प्रारूप प्रदान करता है, जिसका उपयोग सर्वर द्वारा क्लाइंट अनुरोध को चुनौती देने के लिए और क्लाइंट द्वारा प्रमाणीकरण जानकारी प्रदान करने के लिए किया जा सकता है।<ref name="rfc9110">{{cite IETF |rfc=9110 |title=HTTP शब्दार्थ|first1=R. |last1=Fielding |first2=M. |last2=Nottingham |first3=J. |last3=Reschke |publisher=IETF |date=June 2022 |ref=ietf}}</ref>
+एचटीटीपी लक्षित-प्रतिक्रिया प्रमाणीकरण योजनाओं के विस्तृत सेट के माध्यम से अभिगम नियंत्रण और प्रमाणीकरण के लिए सामान्य प्रारूप प्रदान करता है, जिसका उपयोग सर्वर द्वारा क्लाइंट अनुरोध को लक्ष्य देने के लिए और क्लाइंट द्वारा प्रमाणीकरण जानकारी प्रदान करने के लिए किया जा सकता है।<ref name="rfc9110">{{cite IETF |rfc=9110 |title=HTTP शब्दार्थ|first1=R. |last1=Fielding |first2=M. |last2=Nottingham |first3=J. |last3=Reschke |publisher=IETF |date=June 2022 |ref=ietf}}</ref>
 ऊपर वर्णित प्रमाणीकरण तंत्र एचटीटीपी प्रोटोकॉल से संबंधित हैं और क्लाइंट और सर्वर एचटीटीपी सॉफ़्टवेयर द्वारा प्रबंधित (यदि क्लाइंट को या अधिक वेब संसाधनों तक क्लाइंट एक्सेस की अनुमति देने से पूर्व प्रमाणीकरण की आवश्यकता के लिए कॉन्फ़िगर किया गया है), और एचटीटीपी एप्लिकेशन सत्र का उपयोग करने वाले वेब एप्लिकेशन द्वारा नहीं किए जाते हैं।
 === प्रमाणीकरण क्षेत्र ===
-एचटीटीपी प्रमाणीकरण विनिर्देश किसी दिए गए रूट यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (यूआरआई) के लिए सामान्य संसाधनों को और विभाजित करने के लिए इच्छानुसार, कार्यान्वयन-विशिष्ट निर्माण भी प्रदान करता है। वास्तविक मूल्य स्ट्रिंग, यदि उपस्थित है, तो चुनौती के सुरक्षा स्थान घटक को बनाने के लिए कैनोनिकल रूट यूआरआई के साथ जोड़ा जाता है। यह प्रभावी रूप से सर्वर को रूट यूआरआई के अंतर्गत भिन्न-भिन्न प्रमाणीकरण स्कोप को परिभाषित करने की अनुमति देता है।<ref name="rfc9110" />
+एचटीटीपी प्रमाणीकरण विनिर्देश किसी दिए गए रूट यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (यूआरआई) के लिए सामान्य संसाधनों को विभाजित करने के लिए इच्छानुसार, कार्यान्वयन-विशिष्ट निर्माण भी प्रदान करता है। वास्तविक मूल्य स्ट्रिंग, यदि उपस्थित है, तो लक्ष्य के सुरक्षा स्थान घटक को बनाने के लिए कैनोनिकल रूट यूआरआई के साथ जोड़ा जाता है। यह प्रभावी रूप से सर्वर को रूट यूआरआई के अंतर्गत भिन्न-भिन्न प्रमाणीकरण स्कोप को परिभाषित करने की अनुमति देता है।<ref name="rfc9110" />
 == एचटीटीपी आवेदन सत्र ==
 एचटीटीपी स्टेटलेस प्रोटोकॉल है। स्टेटलेस प्रोटोकॉल के लिए वेब सर्वर को एकाधिक अनुरोधों की अवधि के लिए प्रत्येक उपयोगकर्ता के विषय में जानकारी या स्थिति बनाए रखने की आवश्यकता नहीं होती है।
-कुछ वेब एप्लिकेशन को उपयोगकर्ता सत्रों को प्रबंधित करने की आवश्यकता होती है, इसलिए वे उदाहरण के लिए [[HTTP कुकी|एचटीटीपी कुकीज़]] का उपयोग करके राज्यों या [[सत्र (कंप्यूटर विज्ञान)]] को लागू करते हैं<ref>{{Cite journal |last1=Lee |first1=Wei-Bin |last2=Chen |first2=Hsing-Bai |last3=Chang |first3=Shun-Shyan |last4=Chen |first4=Tzung-Her |date=2019-01-25 |title=स्व-सत्यापन के साथ HTTP कुकीज़ के लिए सुरक्षित और कुशल सुरक्षा|url=https://onlinelibrary.wiley.com/doi/10.1002/dac.3857 |journal=International Journal of Communication Systems |language=en |volume=32 |issue=2 |pages=e3857 |doi=10.1002/dac.3857|s2cid=59524143 }}</ref> या छिपे हुए [[चर (कंप्यूटर विज्ञान)]] [[ प्रपत्र (वेब) |प्रपत्र (वेब)]] के अंदर हैं।
+कुछ वेब एप्लिकेशन को उपयोगकर्ता सत्रों को प्रबंधित करने की आवश्यकता होती है, इसलिए वे उदाहरण के लिए [[HTTP कुकी|एचटीटीपी कुकीज़]] का उपयोग करके राज्यों या [[सत्र (कंप्यूटर विज्ञान)]] को प्रारम्भ करते हैं<ref>{{Cite journal |last1=Lee |first1=Wei-Bin |last2=Chen |first2=Hsing-Bai |last3=Chang |first3=Shun-Shyan |last4=Chen |first4=Tzung-Her |date=2019-01-25 |title=स्व-सत्यापन के साथ HTTP कुकीज़ के लिए सुरक्षित और कुशल सुरक्षा|url=https://onlinelibrary.wiley.com/doi/10.1002/dac.3857 |journal=International Journal of Communication Systems |language=en |volume=32 |issue=2 |pages=e3857 |doi=10.1002/dac.3857|s2cid=59524143 }}</ref> या लुप्त हुए [[चर (कंप्यूटर विज्ञान)]] [[ प्रपत्र (वेब) |प्रपत्र (वेब)]] के अंदर हैं।
-एप्लिकेशन उपयोगकर्ता सत्र प्रारंभ करने के लिए, वेब एप्लिकेशन [[लॉग इन करें|लॉगिन]] के माध्यम से इंटरैक्टिव [[प्रमाणीकरण]] किया जाना चाहिए। उपयोगकर्ता सत्र को रोकने के लिए उपयोगकर्ता द्वारा [[ लॉग आउट |लॉग आउट]] ऑपरेशन का अनुरोध किया जाना चाहिए। इस प्रकार के संचालन एचटीटीपी प्रमाणीकरण का उपयोग नहीं करते हैं जबकि कस्टम प्रबंधित वेब अनुप्रयोग प्रमाणीकरण का उपयोग करते हैं।
+एप्लिकेशन उपयोगकर्ता सत्र प्रारंभ करने के लिए, वेब एप्लिकेशन [[लॉग इन करें|लॉगिन]] के माध्यम से इंटरैक्टिव [[प्रमाणीकरण]] किया जाना चाहिए। उपयोगकर्ता सत्र का अवरोध करने के लिए उपयोगकर्ता द्वारा [[ लॉग आउट |लॉग आउट]] ऑपरेशन का अनुरोध किया जाना चाहिए। इस प्रकार के संचालन एचटीटीपी प्रमाणीकरण का उपयोग नहीं करते हैं जबकि कस्टम प्रबंधित वेब अनुप्रयोग प्रमाणीकरण का उपयोग करते हैं।
 == एचटीटीपी/1.1 अनुरोध संदेश ==
@@ Line 212: / Line 212: @@
 क्लाइंट सर्वर को अनुरोध संदेश भेजता है, जिसमें निम्न सम्मिलित हैं:<ref name="rfc9112-2.1">{{cite IETF |rfc=9112 |sectionname=Message format |section=2.1 |title=RFC 9112: HTTP/1.1}}</ref>
 * अनुरोध पंक्ति, जिसमें केस-संवेदी अनुरोध विधि, स्थान (विराम चिह्न), अनुरोधित यूआरएल, अन्य स्थान, प्रोटोकॉल संस्करण, [[कैरिज रिटर्न]] और [[रेखा भरण]] सम्मिलित है, उदाहरण के लिए:
-  /images/logo.png एचटीटीपी/1.1 प्राप्त करें
+  GET /images/logo.png HTTP/1.1
-* शून्य या अधिक एचटीटीपी अनुरोध हेडर फ़ील्ड (एचटीटीपी/1.1 के स्थिति में अल्प से अल्प 1 या अधिक हेडर ), प्रत्येक में केस-असंवेदनशील फ़ील्ड नाम, कोलन, वैकल्पिक अग्रणी व्हाइटस्पेस (कंप्यूटर विज्ञान), फ़ील्ड मान, वैकल्पिक ट्रेलिंग व्हॉट्सएप और कैरिज रिटर्न और लाइन फीड के साथ समाप्त होता है, उदा .:
+* शून्य या अधिक एचटीटीपी अनुरोध हेडर फ़ील्ड के (एचटीटीपी/1.1 के स्थिति में अल्प से अल्प 1 या अधिक हेडर ), प्रत्येक केस-असंवेदनशील फ़ील्ड नाम, कोलन, वैकल्पिक अग्रणी व्हाइटस्पेस (कंप्यूटर विज्ञान), फ़ील्ड मान, वैकल्पिक ट्रेलिंग व्हॉट्सएप और कैरिज रिटर्न और लाइन फीड के साथ समाप्त होता है, उदा .:
-  होस्ट: www.example.com
+  Host: www.example.com
-  स्वीकार-भाषा: en
+  Accept-Language: en
 * रिक्त लाइन, जिसमें कैरिज रिटर्न और रेखा भरण सम्मिलित है;
 * वैकल्पिक एचटीटीपी संदेश निकाय है।
-एचटीटीपी/1.1 प्रोटोकॉल में, <code>Host: hostname</code> को छोड़कर सभी हेडर फ़ील्ड वैकल्पिक हैं।
+एचटीटीपी/1.1 प्रोटोकॉल में, <code>Host: hostname</code> को त्याग कर सभी हेडर फ़ील्ड वैकल्पिक हैं।
-{{IETF RFC|1945}}.<ref name="apacheweek_com-http11">{{cite web |title=अपाचे वीक। एचटीटीपी/1.1|url=https://www.apacheweek.com/features/http11}} 090502 apacheweek.com</ref> में एचटीटीपी / 1.0 विनिर्देश से पूर्व एचटीटीपी क्लाइंट के साथ संगतता बनाए रखने के लिए सर्वर द्वारा केवल पथ नाम वाली अनुरोध पंक्ति को स्वीकार किया जाता है।
+{{IETF RFC|1945}}.<ref name="apacheweek_com-http11">{{cite web |title=अपाचे वीक। एचटीटीपी/1.1|url=https://www.apacheweek.com/features/http11}} 090502 apacheweek.com</ref> में एचटीटीपी/1.0 विनिर्देश से पूर्व एचटीटीपी क्लाइंट के साथ संगतता बनाए रखने के लिए सर्वर द्वारा केवल पथ नाम वाली अनुरोध पंक्ति को स्वीकार किया जाता है।
 === अनुरोध की विधि ===
-[[File:Http request telnet ubuntu.png|thumb|right|टेलनेट का उपयोग करके किया गया एचटीटीपी/1.1 अनुरोध। एचटीटीपी रिक्वेस्ट मैसेज, एचटीटीपी रिस्पांस हेडर सेक्शन और रिस्पॉन्स बॉडी हाइलाइट की गई हैं।]]एचटीटीपी विधियों को (कभी-कभी क्रियाओं के रूप में संदर्भित किया जाता है, किन्तु कहीं भी विनिर्देशन में यह क्रिया का उल्लेख नहीं करता है) पहचाने गए संसाधन पर वांछित क्रिया को इंगित करने के लिए परिभाषित करता है। यह संसाधन क्या दर्शाता है, चाहे पूर्व-उपस्थित डेटा या डेटा जो गतिशील रूप से उत्पन्न होता है, सर्वर के कार्यान्वयन पर निर्भर करता है। प्रायः, संसाधन फ़ाइल या सर्वर पर निष्पादन योग्य के आउटपुट से मेल खाता है। एचटीटीपी/1.0 विनिर्देश<ref name="rfc1945-8">{{cite IETF |rfc=1945 |title=Hypertext Transfer Protocol – HTTP/1.0 |first1=Tim |last1=Berners-Lee |first2=Roy T. |last2=Fielding |first3=Henrik Frystyk |last3=Nielsen |publisher=IETF |sectionname=Method Definitions |section=8 |pages=30–32}}</ref> ने जीईटी, हेड और पोस्ट विधियों को परिभाषित किया, और एचटीटीपी/1.1 विनिर्देश<ref name="rfc2616-9">{{cite IETF |rfc=2616 |sectionname=Method Definitions |section=9 |title=RFC 2616|pages=51–57}}</ref> ने पांच नयी विधि: पुट, डिलीट, कनेक्ट, ऑप्शन और ट्रेस जोड़ी है। कोई भी क्लाइंट किसी भी विधि का उपयोग कर सकता है और सर्वर को विधियों के किसी भी संयोजन का समर्थन करने के लिए कॉन्फ़िगर किया जा सकता है। यदि कोई विधि किसी मध्यवर्ती के लिए अज्ञात है, तो इसे असुरक्षित और [[आलस्य|अनपेक्षित]] विधि के रूप में माना जाएगा। परिभाषित किए जा सकने वाली विधियों की संख्या की कोई सीमा नहीं है, जो उपस्थित मूलभूत प्रारूप को तोड़े बिना भविष्य की विधियों को निर्दिष्ट करने की अनुमति देता है। उदाहरण के लिए, वेबडाव (WebDAV) ने सात नई विधियों को परिभाषित किया और {{IETF RFC|5789}} ने [[पैच क्रिया]] विधि निर्दिष्ट करता है।
+[[File:Http request telnet ubuntu.png|thumb|right|टेलनेट का उपयोग करके किया गया एचटीटीपी/1.1 अनुरोध। एचटीटीपी रिक्वेस्ट मैसेज, एचटीटीपी रिस्पांस हेडर सेक्शन और रिस्पॉन्स बॉडी हाइलाइट की गई हैं।]]एचटीटीपी विधियों को (कभी-कभी क्रियाओं के रूप में संदर्भित किया जाता है, किन्तु कहीं भी विनिर्देशन में यह क्रिया का उल्लेख नहीं करता है) पहचाने गए संसाधन पर वांछित क्रिया को प्रदर्शित करने के लिए परिभाषित करता है। यह संसाधन क्या दर्शाता है, चाहे पूर्व-उपस्थित डेटा जो गतिशील रूप से उत्पन्न होता है, सर्वर के कार्यान्वयन पर निर्भर करता है। प्रायः, संसाधन फ़ाइल या सर्वर पर निष्पादन योग्य के आउटपुट से युग्मित होता है। एचटीटीपी/1.0 विनिर्देश<ref name="rfc1945-8">{{cite IETF |rfc=1945 |title=Hypertext Transfer Protocol – HTTP/1.0 |first1=Tim |last1=Berners-Lee |first2=Roy T. |last2=Fielding |first3=Henrik Frystyk |last3=Nielsen |publisher=IETF |sectionname=Method Definitions |section=8 |pages=30–32}}</ref> ने जीईटी, हेड और पोस्ट विधियों को परिभाषित किया, और एचटीटीपी/1.1 विनिर्देश<ref name="rfc2616-9">{{cite IETF |rfc=2616 |sectionname=Method Definitions |section=9 |title=RFC 2616|pages=51–57}}</ref> ने पांच नयी विधि: पुट, डिलीट, कनेक्ट, ऑप्शन और ट्रेस जोड़ी है। कोई भी क्लाइंट किसी भी विधि का उपयोग कर सकता है और सर्वर को विधियों के किसी भी संयोजन का समर्थन करने के लिए कॉन्फ़िगर किया जा सकता है। यदि कोई विधि किसी मध्यवर्ती के लिए अज्ञात है, तो इसे असुरक्षित और [[आलस्य|अनपेक्षित]] विधि के रूप में माना जाएगा। परिभाषित किए जा सकने वाली विधियों की संख्या की कोई सीमा नहीं है, जो उपस्थित मूलभूत प्रारूप को विभक्त करे बिना भविष्य की विधियों को निर्दिष्ट करने की अनुमति देता है। उदाहरण के लिए, वेबडाव (WebDAV) ने सात नई विधियों को परिभाषित किया और {{IETF RFC|5789}} ने [[पैच क्रिया]] विधि निर्दिष्ट करता है।
 विधि के नाम केस संवेदी होते हैं।<ref name="rfc9112-3">{{cite IETF |rfc=9112 |section=3 |sectionname=Request Line |title=RFC 9112, HTTP/1.1}}</ref><ref name="rfc9110-9.1">{{cite IETF |rfc=9110 |section=9.1 |sectionname=Methods: Overview| title=RFC 9110, HTTP Semantics}}</ref> यह एचटीटीपी हेडर फ़ील्ड नामों के विपरीत है जो केस-असंवेदनशील हैं।<ref name="rfc9110-6.3">{{cite IETF |rfc=9110 |section=6.3 |sectionname=Header Fields |title=RFC 9110, HTTP Semantics}}</ref>
-; जीईटी: जीईटी विधि अनुरोध करती है कि लक्ष्य संसाधन अपने राज्य का प्रतिनिधित्व स्थानांतरित करे। जीईटी अनुरोधों को केवल डेटा पुनर्प्राप्त करना चाहिए और इसका कोई अन्य प्रभाव नहीं होना चाहिए। (यह कुछ अन्य एचटीटीपी विधियों के लिए भी सही है।)<ref name="rfc9110" />परिवर्तन किए बिना संसाधनों को पुनः प्राप्त करने के लिए, पोस्ट पर जीईटी को प्राथमिकता दी जाती है, क्योंकि उन्हें यूआरएल के माध्यम से [[ पता योग्यता |संबोधित]] किया जा सकता हैं। यह बुकमार्क करने और साझा करने में सक्षम बनाता है और [[ब्राउज़र कैश|कैशिंग]] के लिए प्रतिक्रिया प्राप्त करता है, जो बैंडविड्थ को बचा सकता है। [[W3C|डब्ल्यू3सी]] ने इस भेद पर मार्गदर्शन सिद्धांतों को प्रकाशित किया है, जिसमें कहा गया है, "वेब एप्लिकेशन डिज़ाइन को उपरोक्त सिद्धांतों द्वारा सूचित किया जाना चाहिए, किन्तु प्रासंगिक सीमाओं द्वारा भी" सूचित किया जाना चाहिए।<ref>{{cite web |last=Jacobs |first=Ian |title=यूआरआई, एड्रेसेबिलिटी, और एचटीटीपी जीईटी और पोस्ट का उपयोग|url=https://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist |work=Technical Architecture Group finding |publisher=W3C |access-date=26 September 2010 |year=2004}}</ref> नीचे सुरक्षित विधि देखें।
+; जीईटी: जीईटी विधि अनुरोध करती है कि लक्ष्य संसाधन अपने राज्य का प्रतिनिधित्व स्थानांतरित करे। जीईटी अनुरोधों को केवल डेटा पुनर्प्राप्त करना चाहिए और इसका कोई अन्य प्रभाव नहीं होना चाहिए। (यह कुछ अन्य एचटीटीपी विधियों के लिए भी सही है।)<ref name="rfc9110" />परिवर्तन किए बिना संसाधनों को पुनः प्राप्त करने के लिए, पोस्ट पर जीईटी को प्राथमिकता दी जाती है, क्योंकि उन्हें यूआरएल के माध्यम से [[ पता योग्यता |संबोधित]] किया जा सकता हैं। यह बुकमार्क करने और भागीदारी करने में सक्षम बनाता है और [[ब्राउज़र कैश|कैशिंग]] के लिए प्रतिक्रिया प्राप्त करता है, जो बैंडविड्थ को बचा सकता है। [[W3C|डब्ल्यू3सी]] ने इस भेद पर मार्गदर्शन सिद्धांतों को प्रकाशित किया है, जिसमें कहा गया है, "वेब एप्लिकेशन डिज़ाइन को उपरोक्त सिद्धांतों द्वारा सूचित किया जाना चाहिए, किन्तु प्रासंगिक सीमाओं द्वारा भी" सूचित किया जाना चाहिए।<ref>{{cite web |last=Jacobs |first=Ian |title=यूआरआई, एड्रेसेबिलिटी, और एचटीटीपी जीईटी और पोस्ट का उपयोग|url=https://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist |work=Technical Architecture Group finding |publisher=W3C |access-date=26 September 2010 |year=2004}}</ref> नीचे सुरक्षित विधि देखें।
-; हेड: हेड विधि अनुरोध करती है कि लक्ष्य संसाधन जीईटी अनुरोध के लिए अपने राज्य का प्रतिनिधित्व स्थानांतरित करता है, जैसा कि जीईटी अनुरोध के लिए होता है, किन्तु प्रतिक्रिया निकाय में संलग्न प्रतिनिधित्व डेटा के बिना होता है। यह प्रतिक्रिया हेडर  में पूर्ण प्रतिनिधित्व को स्थानांतरित किए बिना, प्रतिनिधित्व मेटाडेटा को पुनर्प्राप्त करने के लिए उपयोगी है। इसके उपयोगों में यह परीक्षण करना सम्मिलित है कि [[HTTP स्थिति कोड|एचटीटीपी स्थिति कोड]] के माध्यम से कोई पृष्ठ उपलब्ध है या नहीं और [[कम्प्यूटर फाइल]] के आकार को शीघ्रता से ज्ञात करना। (<code>Content-Length</code>)
+; हेड: हेड विधि अनुरोध करती है कि लक्ष्य संसाधन जीईटी अनुरोध के लिए अपने राज्य का प्रतिनिधित्व स्थानांतरित करता है, जैसा कि जीईटी अनुरोध के लिए होता है, किन्तु प्रतिक्रिया निकाय में संलग्न प्रतिनिधित्व डेटा के बिना होता है। यह प्रतिक्रिया हेडर में पूर्ण प्रतिनिधित्व को स्थानांतरित किए बिना, प्रतिनिधित्व मेटाडेटा को पुनर्प्राप्त करने के लिए उपयोगी है। इसके उपयोगों में यह परीक्षण करना सम्मिलित है कि [[HTTP स्थिति कोड|एचटीटीपी स्थिति कोड]] के माध्यम से कोई पृष्ठ उपलब्ध है या नहीं और [[कम्प्यूटर फाइल]] के आकार (<code>Content-Length</code>) को शीघ्रता से ज्ञात करना।
-; पोस्ट: [[POST (HTTP)|पोस्ट विधि]] अनुरोध करती है कि लक्ष्य संसाधन लक्ष्य संसाधन के शब्दार्थ के अनुसार अनुरोध में संलग्न प्रतिनिधित्व को संसाधित करता है। उदाहरण के लिए, इसका उपयोग [[इंटरनेट मंच]] पर संदेश पोस्ट करने, [[मेलिंग सूची]] की सदस्यता लेने या [[ऑनलाइन खरीदारी]] लेनदेन को पूर्ण करने के लिए किया जाता है।<ref name="rfc9110-9.3.3">{{cite IETF |rfc=9110 |sectionname=POST |section=9.3.3 |title=RFC 9110, HTTP Semantics}}</ref>
+; पोस्ट: [[POST (HTTP)|पोस्ट विधि]] अनुरोध करती है कि लक्ष्य संसाधन के शब्दार्थ के अनुसार अनुरोध में संलग्न प्रतिनिधित्व को संसाधित करता है। उदाहरण के लिए, इसका उपयोग [[इंटरनेट मंच|इंटरनेट]] पर संदेश पोस्ट करने, [[मेलिंग सूची]] की सदस्यता लेने या [[ऑनलाइन खरीदारी]] लेनदेन को पूर्ण करने के लिए किया जाता है।<ref name="rfc9110-9.3.3">{{cite IETF |rfc=9110 |sectionname=POST |section=9.3.3 |title=RFC 9110, HTTP Semantics}}</ref>
-; पुट: पुट विधि अनुरोध करती है कि लक्ष्य संसाधन अनुरोध में संलग्न प्रतिनिधित्व द्वारा परिभाषित राज्य के साथ अपने राज्य को बनाएं या अपडेट करें। पोस्ट से अंतर यह है कि क्लाइंट सर्वर पर लक्ष्य स्थान निर्दिष्ट करता है।<ref name="rfc9110-9.3.4">{{cite IETF |rfc=9110 |sectionname=PUT |section=9.3.4 |title=RFC 9110, HTTP Semantics}}</ref>
+; पुट: पुट विधि अनुरोध करती है कि लक्ष्य संसाधन अनुरोध में संलग्न प्रतिनिधित्व द्वारा परिभाषित के साथ अपने राज्य को बनाएं या अपडेट करें। पोस्ट से अंतर यह है कि क्लाइंट सर्वर पर लक्ष्य स्थान निर्दिष्ट करता है।<ref name="rfc9110-9.3.4">{{cite IETF |rfc=9110 |sectionname=PUT |section=9.3.4 |title=RFC 9110, HTTP Semantics}}</ref>
 ; डिलीट: डिलीट विधि अनुरोध करती है कि लक्ष्य संसाधन अपनी स्थिति को विस्थापित कर दें।
-; कनेक्ट: कनेक्ट विधि अनुरोध करती है कि मध्यस्थ अनुरोध लक्ष्य द्वारा पहचाने गए मूल सर्वर पर टीसीपी/आईपी सुरंग स्थापित करे। इसका उपयोग प्रायः ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) के साथ एक या एक से अधिक एचटीटीपी प्रॉक्सी के माध्यम से कनेक्शन सुरक्षित करने के लिए किया जाता है।<ref name="rfc9110-9.3.6">{{cite IETF |rfc=9110 |sectionname=CONNECT |section=9.3.6 |title=RFC 9110, HTTP Semantics}}</ref><ref name="HTTP-proxy-arbitrary-TCP">{{cite web |url=https://www.kb.cert.org/vuls/id/150227 |title=Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections |access-date=2007-05-10 |date=2002-05-17 |publisher=[[CERT Coordination Center|US-CERT]]}}</ref>एचटीटीपी कनेक्ट विधि देखें।
+; कनेक्ट: कनेक्ट विधि अनुरोध करती है कि मध्यस्थ अनुरोध लक्ष्य द्वारा पहचाने गए मूल सर्वर पर टीसीपी/आईपी स्थापित करे। इसका उपयोग प्रायः ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) के साथ अधिक एचटीटीपी प्रॉक्सी के माध्यम से कनेक्शन सुरक्षित करने के लिए किया जाता है।<ref name="rfc9110-9.3.6">{{cite IETF |rfc=9110 |sectionname=CONNECT |section=9.3.6 |title=RFC 9110, HTTP Semantics}}</ref><ref name="HTTP-proxy-arbitrary-TCP">{{cite web |url=https://www.kb.cert.org/vuls/id/150227 |title=Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections |access-date=2007-05-10 |date=2002-05-17 |publisher=[[CERT Coordination Center|US-CERT]]}}</ref>एचटीटीपी कनेक्ट विधि देखें।
-; विकल्प: विकल्प विधि अनुरोध करती है कि लक्ष्य संसाधन एचटीटीपी विधियों को स्थानांतरित करता है जो इसका समर्थन करता है। इसका उपयोग किसी विशिष्ट संसाधन के अतिरिक्त '*' अनुरोध करके वेब सर्वर की कार्यक्षमता की परीक्षण करने के लिए किया जा सकता है।
+; विकल्प: विकल्प विधि अनुरोध करती है कि लक्ष्य संसाधन एचटीटीपी विधियों को स्थानांतरित करता है जो इसका समर्थन करता है। इसका उपयोग किसी विशिष्ट संसाधन के अतिरिक्त अनुरोध करके वेब सर्वर की कार्यक्षमता का परीक्षण करने के लिए किया जा सकता है।
-; ट्रेस: ट्रेस विधि अनुरोध करती है कि लक्ष्य संसाधन प्रतिक्रिया निकाय में प्राप्त अनुरोध को स्थानांतरित कर दे। इस प्रकार क्लाइंट देख सकता है कि बिचौलियों द्वारा क्या (यदि कोई हो) परिवर्तन या परिवर्धन किया गया है।
+; ट्रेस: ट्रेस विधि अनुरोध करती है कि लक्ष्य संसाधन प्रतिक्रिया निकाय में प्राप्त अनुरोध को स्थानांतरित कर दे। इस प्रकार क्लाइंट देख सकता है कि मध्यस्थ द्वारा क्या (यदि कोई हो) परिवर्तन या परिवर्धन किया गया है।
 ; पैच: पैच विधि अनुरोध करती है कि लक्ष्य संसाधन अनुरोध में संलग्न प्रतिनिधित्व में परिभाषित आंशिक अद्यतन के अनुसार अपनी स्थिति को संशोधित करता है। यह किसी फ़ाइल या दस्तावेज़ को प्रत्येक प्रकार से स्थानांतरित किए बिना उसका भाग अपडेट करके बैंडविड्थ को बचा सकता है।<ref name="rfc5789">{{cite IETF |rfc=5789 |title=HTTP के लिए पैच विधि|first1=Lisa |last1=Dusseault |first2=James M. |last2=Snell |date=March 2010 |publisher=IETF}}</ref>
@@ Line 332: / Line 332: @@
 ==== सुरक्षित विधि ====
-अनुरोध विधि सुरक्षित है यदि उस विधि के अनुरोध का सर्वर पर कोई प्रभाव नहीं पड़ता है। गेट, हेड, विकल्प और ट्रेस विधियों को सुरक्षित के रूप में परिभाषित किया गया है। दूसरे शब्दों में, सुरक्षित विधियों का उद्देश्य केवल-पढ़ने के लिए है। चूँकि वे [[साइड इफेक्ट (कंप्यूटर विज्ञान)]] को बाहर नहीं करते हैं, जैसे कि [[सर्वर लॉग|लॉग फ़ाइल]] में अनुरोध जानकारी को जोड़ना या विज्ञापन खाते को चार्ज करना, क्योंकि परिभाषा के अनुसार क्लाइंट द्वारा उनका अनुरोध नहीं किया जाता है।
+अनुरोध विधि सुरक्षित है यदि उस विधि के अनुरोध का सर्वर पर कोई प्रभाव नहीं पड़ता है। गेट, हेड, विकल्प और ट्रेस विधियों को सुरक्षित के रूप में परिभाषित किया गया है। दूसरे शब्दों में, सुरक्षित विधियों का उद्देश्य केवल-पढ़ने के लिए है। चूँकि वे [[साइड इफेक्ट (कंप्यूटर विज्ञान)]] को बाहर नहीं करते हैं, जैसे कि [[सर्वर लॉग|लॉग फ़ाइल]] में अनुरोध जानकारी को जोड़ना या विज्ञापन को चार्ज करना, क्योंकि परिभाषा के अनुसार क्लाइंट द्वारा उनका अनुरोध नहीं किया जाता है।
-इसके विपरीत, पोस्ट, पुट, डिलीट, कनेक्ट, और पैच की विधि सुरक्षित नहीं हैं। वे सर्वर की स्थिति को संशोधित कर सकते हैं या [[ईमेल]] भेजने जैसे अन्य प्रभाव डाल सकते हैं। इसलिए ऐसी विधियों का उपयोग सामान्यतः [[इंटरनेट बॉट|वेब रोबोट]] या वेब क्रॉलर के अनुरूप नहीं होते हैं; कुछ जो अनुरूप नहीं हैं, वे संदर्भ या परिणामों की ध्यान किए बिना अनुरोध करते हैं।
+इसके विपरीत, पोस्ट, पुट, डिलीट, कनेक्ट, और पैच की विधि सुरक्षित नहीं हैं। वे सर्वर की स्थिति को संशोधित कर सकते हैं या [[ईमेल]] भेजने जैसे अन्य प्रभाव डाल सकते हैं। इसलिए ऐसी विधियों का उपयोग सामान्यतः [[इंटरनेट बॉट|वेब रोबोट]] या वेब क्रॉलर के अनुरूप नहीं होते हैं; कुछ जो अनुरूप नहीं हैं, वे संदर्भ या परिणामों का ध्यान किए बिना अनुरोध करते हैं।
-जीईटी अनुरोधों की निर्धारित सुरक्षा के अतिरिक्त, व्यवहार में सर्वर द्वारा उनकी हैंडलिंग किसी भी प्रकार से प्रौद्योगिकी रूप से सीमित नहीं है। लापरवाह या जानबूझकर अनियमित प्रोग्रामिंग जीईटी अनुरोधों को सर्वर पर अन्य-मूल्यहीन परिवर्तन करने की अनुमति दे सकती है। वेब कैशिंग, [[खोज इंजन|शोध इंजन]] और अन्य स्वचालित एजेंटों द्वारा सर्वर पर अनपेक्षित परिवर्तन करने पर उत्पन्न होने वाली समस्याओं के कारण इसे हतोत्साहित किया जाता है। उदाहरण के लिए, वेबसाइट <nowiki>https://example.com/article/1234/delete</nowiki> जैसे किसी यूआरएल के माध्यम से किसी संसाधन को विस्थापित करने की अनुमति दे सकती है, जो यदि इच्छानुसार प्रकार से प्राप्त किया जाता है, यहां तक कि जीईटी का उपयोग करते हुए भी, लेख को सरलता से विस्थापित कर देगा।<ref name="oreilly-get-rails">{{cite book |last=Ediger |first=Brad |date=2007-12-21 |title=Advanced Rails: Building Industrial-Strength Web Apps in Record Time |url=https://shop.oreilly.com/product/9780596510329.do |publisher=O'Reilly Media, Inc. |page=188 |isbn= 978-0596519728 |quote=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.}}</ref> उत्तम प्रकार से कोडित वेबसाइट को इस क्रिया के लिए डिलीट या पोस्ट विधि की आवश्यकता होगी, जो अन्य-दुर्भावनापूर्ण बॉट्स नहीं करेंगे।
+जीईटी अनुरोधों की निर्धारित सुरक्षा के अतिरिक्त, व्यवहार में सर्वर द्वारा उनकी हैंडलिंग किसी भी प्रकार से प्रौद्योगिकी रूप से सीमित नहीं है। असावधान या निश्चयपूर्वक अनियमित प्रोग्रामिंग जीईटी अनुरोधों को सर्वर पर अन्य-मूल्यहीन परिवर्तन करने की अनुमति दे सकती है। वेब कैशिंग, [[खोज इंजन|शोध इंजन]] और अन्य स्वचालित एजेंटों द्वारा सर्वर पर अनपेक्षित परिवर्तन करने पर उत्पन्न होने वाली समस्याओं के कारण इसे हतोत्साहित किया जाता है। उदाहरण के लिए, वेबसाइट <nowiki>https://example.com/article/1234/delete</nowiki> जैसे किसी यूआरएल के माध्यम से किसी संसाधन को विस्थापित करने की अनुमति दे सकती है, जो इच्छानुसार प्रकार से प्राप्त किया जाता है, यहां तक कि जीईटी का उपयोग करते हुए भी, लेख को सरलता से विस्थापित कर देगा।<ref name="oreilly-get-rails">{{cite book |last=Ediger |first=Brad |date=2007-12-21 |title=Advanced Rails: Building Industrial-Strength Web Apps in Record Time |url=https://shop.oreilly.com/product/9780596510329.do |publisher=O'Reilly Media, Inc. |page=188 |isbn= 978-0596519728 |quote=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.}}</ref> उत्तम प्रकार से कोडित वेबसाइट को इस क्रिया के लिए डिलीट या पोस्ट विधि की आवश्यकता होगी, जो अन्य-दुर्भावनापूर्ण बॉट्स नहीं करेंगे।
-अभ्यास में ऐसा होने का उदाहरण अल्पकालिक [[Google वेब त्वरक|गूगल वेब त्वरक]] बीटा परीक्षण के समय था, जो उपयोगकर्ता द्वारा देखे जा रहे पृष्ठ पर इच्छानुसार यूआरएल को प्रीफ़ेच करता था, जिससे रिकॉर्ड स्वचालित रूप से परिवर्तित कर दिए जाते थे या सामूहिक रूप से विस्थापित कर दिए जाते थे। व्यापक आलोचना के पश्चात, बीटा को इसकी प्रथमरिलीज के कुछ सप्ताह पश्चात ही निलंबित कर दिया गया था।<ref>{{cite web |url=https://blogs.adobe.com/cantrell/archives/2005/06/what_have_we_le.html |title=What Have We Learned From the Google Web Accelerator? |last=Cantrell |first=Christian |archive-url=https://web.archive.org/web/20170819161233/https://blogs.adobe.com/cantrell/archives/2005/06/what_have_we_le.html |archive-date=2017-08-19 |date=2005-06-01 |website=Adobe Blogs |publisher=Adobe |access-date=2018-11-19 |url-status=dead }}</ref><ref name="oreilly-get-rails" />
+अभ्यास में ऐसा होने का उदाहरण अल्पकालिक [[Google वेब त्वरक|गूगल वेब त्वरक]] बीटा परीक्षण के समय था, जो उपयोगकर्ता द्वारा देखे जा रहे पृष्ठ पर इच्छानुसार यूआरएल को प्रीफ़ेच करता था, जिससे रिकॉर्ड स्वचालित रूप से परिवर्तित कर दिए जाते थे या सामूहिक रूप से विस्थापित कर दिए जाते थे। व्यापक आलोचना के पश्चात, बीटा को इसकी प्रथम प्रस्तावित के कुछ सप्ताह पश्चात ही निलंबित कर दिया गया था।<ref>{{cite web |url=https://blogs.adobe.com/cantrell/archives/2005/06/what_have_we_le.html |title=What Have We Learned From the Google Web Accelerator? |last=Cantrell |first=Christian |archive-url=https://web.archive.org/web/20170819161233/https://blogs.adobe.com/cantrell/archives/2005/06/what_have_we_le.html |archive-date=2017-08-19 |date=2005-06-01 |website=Adobe Blogs |publisher=Adobe |access-date=2018-11-19 |url-status=dead }}</ref><ref name="oreilly-get-rails" />
 ==== निष्कार्य विधि ====
 {{see also|उदासीनता कंप्यूटर विज्ञान अर्थ}}
-अनुरोध विधि उदासीन है यदि उस विधि के साथ अनेक समान अनुरोधों का एक ही अनुरोध के समान प्रभाव होता है। पुट और डिलीट की विधि, और सुरक्षित विधियों को निष्कार्य के रूप में परिभाषित किया गया है। सुरक्षित विधि मूल्यहीन रूप से निष्कार्य हैं, क्योंकि उनका उद्देश्य सर्वर पर किसी भी प्रकार का प्रभाव नहीं डालना है; इस मध्य, पुट और डिलीट विधियाँ उदासीन हैं क्योंकि क्रमिक समान अनुरोधों को उपेक्षित कर दिया जाएगा। उदाहरण के लिए, वेबसाइट उपयोगकर्ता के रिकॉर्ड किए गए ईमेल पते को संशोधित करने के लिए पुट समापन बिंदु सेट कर सकती है। यदि यह समापन बिंदु सही प्रकार से कॉन्फ़िगर किया गया है, तो कोई भी अनुरोध जो उपयोगकर्ता के ईमेल पते को उसी ईमेल पते में परिवर्तित करने के लिए कहता है जो पूर्व से ही रिकॉर्ड किया गया है—उदा. सफल अनुरोध के पश्चात डुप्लिकेट अनुरोध—कोई प्रभाव नहीं पड़ेगा। इसी प्रकार, किसी निश्चित उपयोगकर्ता को विस्थापित करने के अनुरोध का कोई प्रभाव नहीं पड़ेगा यदि वह उपयोगकर्ता पूर्व में ही विस्थापित कर दिया गया हो।
+अनुरोध विधि उदासीन है यदि उस विधि के साथ अनेक समान अनुरोधों के समान प्रभाव होता है। पुट और डिलीट की विधि, और सुरक्षित विधियों को निष्कार्य के रूप में परिभाषित किया गया है। सुरक्षित विधि मूल्यहीन रूप से निष्कार्य हैं, क्योंकि उनका उद्देश्य सर्वर पर किसी भी प्रकार का प्रभाव नहीं डालना है; इस मध्य, पुट और डिलीट विधियाँ उदासीन हैं क्योंकि क्रमिक समान अनुरोधों को उपेक्षित कर दिया जाएगा। उदाहरण के लिए, वेबसाइट उपयोगकर्ता के रिकॉर्ड किए गए ईमेल एड्रेस को संशोधित करने के लिए पुट समापन बिंदु सेट कर सकती है। यदि यह समापन बिंदु सही प्रकार से कॉन्फ़िगर किया गया है, तो कोई भी अनुरोध जो उपयोगकर्ता के ईमेल एड्रेस को उसी ईमेल एड्रेस में परिवर्तित करने के लिए कहता है जो पूर्व से ही रिकॉर्ड किया गया है—उदा. सफल अनुरोध के पश्चात डुप्लिकेट अनुरोध—कोई प्रभाव नहीं पड़ेगा। इसी प्रकार, किसी निश्चित उपयोगकर्ता को विस्थापित करने के अनुरोध का कोई प्रभाव नहीं पड़ेगा यदि वह उपयोगकर्ता पूर्व में ही विस्थापित कर दिया गया हो।
-इसके विपरीत, विधियाँ पोस्ट, कनेक्ट, और पैच आवश्यक रूप से निष्क्रिय नहीं हैं, और इसलिए समान पोस्ट अनुरोध को अनेक बार भेजने से सर्वर की स्थिति में और परिवर्तन हो सकता है या आगे के प्रभाव हो सकते हैं, जैसे कि अनेक ईमेल भेजना सम्मिलित हैं। कुछ स्तिथियों में यह वांछित प्रभाव है, किन्तु अन्य स्तिथियों में यह आकस्मिक रूप से हो सकता है। उपयोगकर्ता, उदाहरण के लिए, अनजाने में बटन को पुनः क्लिक करके अनेक पोस्ट अनुरोध भेज सकता है यदि उन्हें स्पष्ट प्रतिक्रिया नहीं दी गई थी कि प्रथम क्लिक संसाधित किया जा रहा था। जबकि वेब ब्राउज़र कुछ स्तिथियों में उपयोगकर्ताओं को चेतावनी देने के लिए [[अलर्ट डायलॉग बॉक्स]] दिखा सकते हैं, जहां पृष्ठ को पुनः लोड करने से पोस्ट अनुरोध पुनः सबमिट हो सकता है, यह सामान्यतः उन स्तिथियों को संभालने के लिए वेब एप्लिकेशन पर निर्भर करता है जहां पोस्ट अनुरोध से अधिक बार सबमिट नहीं किया जाना चाहिए।
+इसके विपरीत, विधियाँ पोस्ट, कनेक्ट, और पैच आवश्यक रूप से निष्क्रिय नहीं हैं, और इसलिए समान पोस्ट अनुरोध को अनेक बार भेजने से सर्वर की स्थिति में परिवर्तन हो सकता है या आगे के प्रभाव हो सकते हैं, जैसे कि अनेक ईमेल भेजना सम्मिलित हैं। कुछ स्तिथियों में यह वांछित प्रभाव है, किन्तु अन्य स्तिथियों में यह आकस्मिक रूप से हो सकता है। उपयोगकर्ता, उदाहरण के लिए, अज्ञात में बटन को पुनः क्लिक करके अनेक पोस्ट अनुरोध भेज सकता है यदि उन्हें स्पष्ट प्रतिक्रिया नहीं दी गई थी कि प्रथम क्लिक संसाधित किया जा रहा था। जबकि वेब ब्राउज़र कुछ स्तिथियों में उपयोगकर्ताओं को लक्ष्य देने के लिए [[अलर्ट डायलॉग बॉक्स]] दिखा सकते हैं, जहां पृष्ठ को पुनः लोड करने से पोस्ट अनुरोध पुनः सबमिट हो सकता है, यह सामान्यतः उन स्तिथियों को संभालने के लिए वेब एप्लिकेशन पर निर्भर करता है जहां पोस्ट अनुरोध से अधिक बार सबमिट नहीं किया जाना चाहिए।
-ध्यान दें कि कोई विधि निष्क्रिय है या नहीं, प्रोटोकॉल या वेब सर्वर द्वारा लागू नहीं किया जाता है। वेब एप्लिकेशन लिखना प्रत्येक प्रकार से संभव है जिसमें (उदाहरण के लिए) डेटाबेस इन्सर्ट या अन्य नॉन-इम्पोटेंट एक्शन को जीईटी या अन्य अनुरोध द्वारा ट्रिगर किया जाता है। सिफारिशों के विरुद्ध ऐसा करने के लिए, चूँकि , अवांछित परिणाम हो सकते हैं, यदि कोई उपयोगकर्ता एजेंट मानता है कि ही अनुरोध को दोहराना सुरक्षित है, जबकि ऐसा नहीं है।
+ध्यान दें कि कोई विधि निष्क्रिय है या नहीं, प्रोटोकॉल या वेब सर्वर द्वारा प्रारम्भ नहीं किया जाता है। वेब एप्लिकेशन लिखना प्रत्येक प्रकार से संभव है जिसमें (उदाहरण के लिए) डेटाबेस इन्सर्ट या अन्य नॉन-इम्पोटेंट एक्शन को जीईटी या अन्य अनुरोध द्वारा ट्रिगर किया जाता है। अनुरोध के विरुद्ध ऐसा करने के लिए, चूँकि, अवांछित परिणाम हो सकते हैं, यदि कोई उपयोगकर्ता एजेंट मानता है कि ही अनुरोध को दोहराना सुरक्षित है, जबकि ऐसा नहीं है।
 ==== प्राप्य विधि ====
 {{see also|वेब कैश}}
-अनुरोध विधि कैश करने योग्य है यदि उस विधि के अनुरोधों के जवाब भविष्य में पुन: उपयोग के लिए संग्रहीत किए जा सकते हैं। विधियों गेट, हेड और पोस्ट को कैश करने योग्य के रूप में परिभाषित किया गया है।
+अनुरोध विधि कैश करने योग्य है यदि उस विधि के अनुरोधों का उत्तर भविष्य में पुन: उपयोग के लिए संग्रहीत किए जा सकते हैं। विधियों गेट, हेड और पोस्ट को कैश करने योग्य के रूप में परिभाषित किया गया है।
 इसके विपरीत, पुट, डिलीट, कनेक्ट, विकल्प, ट्रेस, और पैच की विधि उपलब्ध नहीं हैं।
@@ Line 356: / Line 356: @@
 === हेडर फ़ील्ड का अनुरोध करें ===
 {{see also|एचटीटीपी हेडर फ़ील्ड की सूची अनुरोध फ़ील्ड}}
-अनुरोध हेडर फ़ील्ड क्लाइंट को अनुरोध संशोधक (प्रक्रिया के पैरामीटर के समान) के रूप में कार्य करते हुए अनुरोध पंक्ति से परे अतिरिक्त जानकारी पास करने की अनुमति देती है। वे क्लाइंट के विषय में, लक्ष्य संसाधन के विषय में, या अनुरोध के अपेक्षित संचालन के विषय में जानकारी देते हैं।
+अनुरोध हेडर फ़ील्ड क्लाइंट को अनुरोध संशोधक (प्रक्रिया के पैरामीटर के समान) के रूप में कार्य करते हुए अनुरोध पंक्ति के अतिरिक्त जानकारी करने की अनुमति देती है। वे क्लाइंट के विषय में, लक्ष्य संसाधन के विषय में, या अनुरोध के अपेक्षित संचालन के विषय में जानकारी देते हैं।
 == एचटीटीपी/1.1 प्रतिक्रिया संदेश ==
@@ Line 365: / Line 365: @@
 * स्थिति रेखा, जिसमें प्रोटोकॉल संस्करण, स्थान (विराम चिह्न), प्रतिक्रिया स्थिति कोड, अन्य स्थान, संभावित रिक्त कारण वाक्यांश, कैरिज रिटर्न और पंक्ति फीड सम्मिलित है, उदाहरण के लिए:
-  एचटीटीपी/1.1 200 उचित है
+  HTTP/1.1 200 OK
 * शून्य या अधिक एचटीटीपी प्रतिक्रिया हेडर फ़ील्ड, प्रत्येक में केस-असंवेदनशील फ़ील्ड नाम, कोलन, वैकल्पिक अग्रणी व्हाइटस्पेस (कंप्यूटर विज्ञान), फ़ील्ड मान, वैकल्पिक अनुगामी व्हाइटस्पेस और कैरिज रिटर्न और पंक्ति फीड के साथ समाप्त होता है, उदाहरण के लिए :
-  सामग्री-प्रकार: पाठ/एचटीएमएल
+  Content-Type: text/html
 * रिक्त पंक्ति, जिसमें कैरिज रिटर्न और पंक्ति फीड सम्मिलित है;
 * वैकल्पिक एचटीटीपी संदेश निकाय है।
@@ Line 373: / Line 374: @@
 === प्रतिक्रिया स्थिति कोड ===
 {{See also|एचटीटीपी स्थिति कोड की सूची}}
-एचटीटीपी/1.0 और उसके पश्चात से, एचटीटीपी प्रतिक्रिया की प्रथमपंक्ति को स्थिति रेखा कहा जाता है और इसमें संख्यात्मक स्थिति कोड (जैसे [[HTTP 404|एचटीटीपी 404]]) और शाब्दिक कारण वाक्यांश (जैसे "नहीं मिला") सम्मिलित होता है। प्रतिक्रिया स्थिति कोड तीन अंकों का पूर्णांक कोड है जो क्लाइंट के संबंधित अनुरोध को समझने और संतुष्ट करने के सर्वर के प्रयास के परिणाम का प्रतिनिधित्व करता है। जिस प्रकार से क्लाइंट प्रतिक्रिया को संभालता है वह मुख्य रूप से स्थिति कोड पर निर्भर करता है, और दूसरा प्रतिक्रिया हेडर फ़ील्ड पर निर्भर करता है। क्लाइंट सभी पंजीकृत स्थिति कोड को नहीं समझ सकते हैं, किन्तु उन्हें अपनी कक्षा (स्थिति कोड के पूर्व अंक द्वारा दी गई) को समझना चाहिए और उस वर्ग के x00 स्थिति कोड के समान होने के लिए अन्य-मान्यता प्राप्त स्थिति कोड का उपचार करना चाहिए।
+एचटीटीपी/1.0 और उसके पश्चात से, एचटीटीपी प्रतिक्रिया की प्रथम पंक्ति को स्थिति रेखा कहा जाता है और इसमें संख्यात्मक स्थिति कोड (जैसे [[HTTP 404|एचटीटीपी 404]]) और शाब्दिक कारण वाक्यांश (जैसे "नहीं मिला") सम्मिलित होता है। प्रतिक्रिया स्थिति कोड तीन अंकों का पूर्णांक कोड है जो क्लाइंट के संबंधित अनुरोध को समझने और संतुष्ट करने के सर्वर के प्रयास के परिणाम का प्रतिनिधित्व करता है। जिस प्रकार से क्लाइंट प्रतिक्रिया को संभालता है वह मुख्य रूप से स्थिति कोड पर निर्भर करता है, और दूसरा प्रतिक्रिया हेडर फ़ील्ड पर निर्भर करता है। क्लाइंट सभी पंजीकृत स्थिति कोड को नहीं समझ सकते हैं, किन्तु उन्हें अपनी कक्षा (स्थिति कोड के पूर्व अंक द्वारा दी गई) को समझना चाहिए और उस वर्ग के x00 स्थिति कोड के समान होने के लिए अन्य-मान्यता प्राप्त स्थिति कोड का उपचार करना चाहिए।
-मानक कारण वाक्यांश केवल अनुशंसाएँ हैं, और वेब डेवलपर के विवेक पर स्थानीय समकक्षों के साथ परिवर्तित किये जा सकते हैं। यदि स्थिति कोड किसी समस्या का संकेत देता है, तो उपयोगकर्ता एजेंट समस्या की प्रकृति के विषय में अधिक जानकारी प्रदान करने के लिए उपयोगकर्ता को कारण वाक्यांश प्रदर्शित कर सकता है। मानक भी उपयोगकर्ता एजेंट को कारण वाक्यांश की व्याख्या करने का प्रयास करने की अनुमति देता है, चूँकि यह नासमझी हो सकती है क्योंकि मानक स्पष्ट रूप से निर्दिष्ट करता है कि स्थिति कोड मशीन-पठनीय हैं और कारण वाक्यांश मानव-पठनीय हैं।
+मानक कारण वाक्यांश केवल अनुशंसाएँ हैं, और वेब डेवलपर के विवेक पर स्थानीय समकक्षों के साथ परिवर्तित किये जा सकते हैं। यदि स्थिति कोड किसी समस्या का संकेत देता है, तो उपयोगकर्ता एजेंट समस्या की प्रकृति के विषय में अधिक जानकारी प्रदान करने के लिए उपयोगकर्ता को कारण वाक्यांश प्रदर्शित कर सकता है। मानक भी उपयोगकर्ता एजेंट को कारण वाक्यांश की व्याख्या करने का प्रयास करने की अनुमति देता है, चूँकि यह अज्ञानता हो सकती है क्योंकि मानक स्पष्ट रूप से निर्दिष्ट करता है कि स्थिति कोड मशीन-पठनीय हैं और कारण वाक्यांश मानव-पठनीय हैं।
 स्थिति कोड का प्रथम अंक इसकी कक्षा को परिभाषित करता है:
@@ Line 383: / Line 384: @@
 ; <code>2XX</code> (सफल): अनुरोध सफलतापूर्वक प्राप्त हुआ, समझा गया और स्वीकार किया गया।
-; <code>3XX</code> (पुनर्निर्देशन): अनुरोध को पूर्ण करने के लिए आगे की कार्रवाई करने की आवश्यकता है।
+; <code>3XX</code> (पुनर्निर्देशन): अनुरोध को पूर्ण करने के लिए आगे की कार्यावधि करने की आवश्यकता है।
-; <code>4XX</code> (क्लाइंट त्रुटि): अनुरोध में खराब सिंटैक्स है या इसे पूर्ण नहीं किया जा सकता है।
+; <code>4XX</code> (क्लाइंट त्रुटि): अनुरोध में अवस्था सिंटैक्स है या इसे पूर्ण नहीं किया जा सकता है।
 ; <code>5XX</code> (सर्वर त्रुटि): सर्वर स्पष्ट रूप से मान्य अनुरोध को पूर्ण करने में विफल रहा।
@@ Line 391: / Line 392: @@
 === प्रतिक्रिया हेडर फ़ील्ड ===
 {{see also|एचटीटीपी हेडर फ़ील्ड्स की सूची प्रतिक्रिया फ़ील्ड्स}}
-प्रतिक्रिया हेडर फ़ील्ड सर्वर को प्रतिक्रिया संशोधक के रूप में कार्य करते हुए स्थिति रेखा से परे अतिरिक्त जानकारी पास करने की अनुमति देती है। वे सर्वर के विषय में या लक्षित संसाधन या संबंधित संसाधनों तक और एक्सेसके विषय में जानकारी देते हैं।
+प्रतिक्रिया हेडर फ़ील्ड सर्वर को प्रतिक्रिया संशोधक के रूप में कार्य करते हुए स्थिति रेखा के अतिरिक्त जानकारी पास करने की अनुमति देती है। वे सर्वर के विषय में या लक्षित संसाधन या संबंधित संसाधनों तक और एक्सेस के विषय में जानकारी देते हैं।
 प्रत्येक प्रतिक्रिया हेडर फ़ील्ड का परिभाषित अर्थ होता है जिसे अनुरोध विधि या प्रतिक्रिया स्थिति कोड के शब्दार्थ द्वारा और अधिक परिष्कृत किया जा सकता है।
@@ Line 409: / Line 410: @@
 </syntaxhighlight>
-क्लाइंटअनुरोध (अनुरोध पंक्ति के इस स्थिति में और कुछ हेडर  सम्मिलित हैं जिन्हें केवल <code>"Host: hostname"</code> हेडर) के पश्चात रिक्त रेखा होती है, जिससे कि अनुरोध पंक्ति के दोहरे सिरे के साथ समाप्त हो, प्रत्येक कैरिज रिटर्न के रूप में और उसके पश्चात लाइन फीड हो। <code>"Host: hostname"</code> e> हेडर मान विभिन्न [[डोमेन की नामांकन प्रणाली]] नामों के मध्य एकल आईपी पता साझा करने के मध्य अंतर करता है, जिससे नाम-आधारित वर्चुअल होस्टिंग की अनुमति मिलती है। जबकि एचटीटीपी/1.0 में वैकल्पिक है, एचटीटीपी/1.1 में यह अनिवार्य है। (A "/" (स्लैश) सामान्यतः वेबसर्वर डायरेक्टरी इंडेक्स|/index.html फ़ाइल लाएगा यदि कोई है।)
+क्लाइंट अनुरोध (अनुरोध पंक्ति के इस स्थिति में और कुछ हेडर सम्मिलित हैं जिन्हें केवल <code>"Host: hostname"</code> हेडर) के पश्चात रिक्त रेखा होती है, जिससे कि अनुरोध पंक्ति के दोहरे सिरे के साथ समाप्त हो, प्रत्येक कैरिज रिटर्न के रूप में और उसके पश्चात लाइन फीड हो। <code>"Host: hostname"</code> e> हेडर मान विभिन्न [[डोमेन की नामांकन प्रणाली]] नामों के मध्य एकल आईपी एड्रेस करने के मध्य अंतर करता है, जिससे नाम-आधारित वर्चुअल होस्टिंग की अनुमति मिलती है। जबकि एचटीटीपी/1.0 में वैकल्पिक है, एचटीटीपी/1.1 में यह अनिवार्य है। (A "/" (स्लैश) सामान्यतः वेबसर्वर डायरेक्टरी इंडेक्स/index.html फ़ाइल लाएगा यदि कोई है।)
 === सर्वर प्रतिक्रिया ===
@@ Line 432: / Line 433: @@
 </html>
 </syntaxhighlight>
-[[HTTP ETag|ETag]] (एंटिटी टैग) हेडर फ़ील्ड का उपयोग यह निर्धारित करने के लिए किया जाता है कि अनुरोधित संसाधन का कैश्ड संस्करण सर्वर पर संसाधन के वर्तमान संस्करण के समान है या नहीं। <code>"Content-Type"</code> एचटीटीपी संदेश द्वारा बताए गए डेटा के [[इंटरनेट मीडिया प्रकार]] को निर्दिष्ट करता है, जबकि <code>"Content-Length"</code> बाइट्स में इसकी लंबाई इंगित करता है। एचटीटीपी/1.1 वेबसर्वर फ़ील्ड सेट करके दस्तावेज़ की कुछ बाइट श्रेणियों के अनुरोधों का जवाब देने की अपनी क्षमता प्रकाशित करता है <code>"Accept-Ranges: bytes"</code>. यह उपयोगी है, यदि क्लाइंटको केवल कुछ भाग ही चाहिए<ref>{{cite IETF |draft=draft-ietf-http-range-retrieval-00 |title=HTTP के लिए बाइट रेंज रिट्रीवल एक्सटेंशन|first1=Ari |last1=Luotonen |first2=John |last2=Franks |publisher=IETF |date=February 22, 1996}}</ref> सर्वर द्वारा भेजे गए संसाधन का, जिसे बाइट सर्विंग कहा जाता है। कब <code>"Connection: close"</code> भेजा जाता है, इसका तात्पर्य है कि वेब सर्वर इस प्रतिक्रिया के हस्तांतरण के अंत के तुरंत पश्चात ट्रांसमिशन कंट्रोल प्रोटोकॉल कनेक्शन बंद कर देगा।<ref name="rfc9112-9.1" />
+[[HTTP ETag|ETag]] (एंटिटी टैग) हेडर फ़ील्ड का उपयोग यह निर्धारित करने के लिए किया जाता है कि अनुरोधित संसाधन का कैश्ड संस्करण सर्वर पर संसाधन के वर्तमान संस्करण के समान है या नहीं। <code>"Content-Type"</code> एचटीटीपी संदेश द्वारा बताए गए डेटा के [[इंटरनेट मीडिया प्रकार]] को निर्दिष्ट करता है, जबकि <code>"Content-Length"</code> बाइट्स में इसकी लंबाई प्रदर्शित करता है। एचटीटीपी/1.1 वेबसर्वर फ़ील्ड सेट करके दस्तावेज़ की कुछ बाइट श्रेणियों के अनुरोधों का उत्तर देने की अपनी क्षमता  <code>"Accept-Ranges: bytes"</code> प्रकाशित करता है, यह उपयोगी है, यदि क्लाइंट को केवल कुछ भाग ही चाहिए<ref>{{cite IETF |draft=draft-ietf-http-range-retrieval-00 |title=HTTP के लिए बाइट रेंज रिट्रीवल एक्सटेंशन|first1=Ari |last1=Luotonen |first2=John |last2=Franks |publisher=IETF |date=February 22, 1996}}</ref> सर्वर द्वारा भेजे गए संसाधन का, जिसे बाइट सर्विंग कहा जाता है। कब <code>"Connection: close"</code> भेजा जाता है, इसका तात्पर्य है कि वेब सर्वर इस प्रतिक्रिया के हस्तांतरण के अंत के तुरंत पश्चात ट्रांसमिशन कंट्रोल प्रोटोकॉल कनेक्शन बंद कर देगा।<ref name="rfc9112-9.1" />
-अधिकांश हेडर लाइन वैकल्पिक हैं किन्तु कुछ अनिवार्य हैं। जब हेडर <code>"Content-Length: number"</code> इकाई निकाय के साथ प्रतिक्रिया में गुम है तो इसे एचटीटीपी /1.0 में त्रुटि माना जाना चाहिए किन्तु हेडर होने पर एचटीटीपी/1.1 में यह त्रुटि नहीं हो सकती है <code>"Transfer-Encoding: chunked"</code> उपस्थित है। चंक्ड ट्रांसफर एन्कोडिंग सामग्री के अंत को चिह्नित करने के लिए 0 के चंक आकार का उपयोग करता है। एचटीटीपी/1.0 के कुछ प्राचीन कार्यान्वयनों ने हेडर को छोड़ दिया <code>"Content-Length"</code> जब प्रतिक्रिया की प्रारंभ में शरीर इकाई की लंबाई ज्ञात नहीं थी और इसलिए क्लाइंट को डेटा का स्थानांतरण तब तक निरंतर रहा जब तक कि सर्वर ने सॉकेट बंद नहीं कर दिया।
+अधिकांश हेडर लाइन वैकल्पिक हैं किन्तु कुछ अनिवार्य हैं। जब हेडर <code>"Content-Length: number"</code> इकाई निकाय के साथ प्रतिक्रिया में लुप्त है तो इसे एचटीटीपी/1.0 में त्रुटि माना जाना चाहिए किन्तु हेडर होने पर एचटीटीपी/1.1 में यह त्रुटि नहीं हो सकती है <code>"Transfer-Encoding: chunked"</code> उपस्थित है। चंक्ड ट्रांसफर एन्कोडिंग सामग्री के अंत को चिह्नित करने के लिए 0 के चंक आकार का उपयोग करता है। एचटीटीपी/1.0 के कुछ प्राचीन कार्यान्वयनों ने हेडर को त्याग दिया <code>"Content-Length"</code> जब प्रतिक्रिया की प्रारंभ में शरीर इकाई की लंबाई ज्ञात नहीं थी और इसलिए क्लाइंट को डेटा का स्थानांतरण तब तक निरंतर रहा जब तक कि सर्वर ने सॉकेट बंद नहीं कर दिया।
-A <code>"Content-Encoding: [[gzip]]"</code> क्लाइंट को सूचित करने के लिए उपयोग किया जा सकता है कि ट्रांसमिटेड डेटा का बॉडी एंटिटी पार्ट gzip एल्गोरिथम द्वारा संपीड़ित किया गया है।
+A <code>"Content-Encoding: [[gzip]]"</code> क्लाइंट को सूचित करने के लिए उपयोग किया जा सकता है कि ट्रांसमिटेड डेटा का बॉडी एंटिटी पार्ट जीजेडआईपी एल्गोरिथम द्वारा उपयोग किया गया है।
 == एन्क्रिप्टेड कनेक्शन ==
@@ Line 442: / Line 443: @@
 == समान प्रोटोकॉल ==
 * [[गोफर (प्रोटोकॉल)]] सामग्री वितरण प्रोटोकॉल है जिसे 1990 के दशक के प्रारंभ में एचटीटीपी द्वारा विस्थापित किया गया था।
-* स्पीडी (SPDY) प्रोटोकॉल, गूगल द्वारा विकसित एचटीटीपी का विकल्प है, जिसका स्थान एचटीटीपी/2 ने ले लिया है।
+* स्पीडी प्रोटोकॉल, गूगल द्वारा विकसित एचटीटीपी का विकल्प है, जिसका स्थान एचटीटीपी/2 ने ग्रहण कर लिया है।
 * [[ मिथुन (प्रोटोकॉल) | जेमिनी प्रोटोकॉल]] गोफर-प्रेरित प्रोटोकॉल है जो गोपनीयता से संबंधित सुविधाओं को अनिवार्य करता है।
 == यह भी देखें ==
-{{HTTP}}
+* अंतर्ग्रहीय फाइल प्रणाली- एचटीटीपी का स्थान ग्रहण कर सकता है
-* अंतर्ग्रहीय फाइल प्रणाली - http की स्थान ले सकता है
 * [[फ़ाइल स्थानांतरण प्रोटोकॉल की तुलना]]
-* विवश अनुप्रयोग प्रोटोकॉल - एचटीटीपी के लिए शब्दार्थ के समान प्रोटोकॉल किन्तु सीमित प्रसंस्करण क्षमता वाले उपकरणों के लिए लक्षित UDP या UDP जैसे संदेशों का उपयोग किया जाता है; एचटीटीपी और इंटरनेट मीडिया प्रकार और वेब लिंकिंग जैसी अन्य इंटरनेट अवधारणाओं का पुन: उपयोग करता है (<nowiki>RFC 5988</nowiki>)<ref name="rfc5988">{{cite IETF |rfc=5988 |title=वेब लिंकिंग|first1=Mark |last1=Nottingham |publisher=IETF |date=October 2010}}</ref>
+* विवश अनुप्रयोग प्रोटोकॉल- एचटीटीपी के लिए शब्दार्थ के समान प्रोटोकॉल किन्तु सीमित प्रसंस्करण क्षमता वाले उपकरणों के लिए लक्षित यूडीपी जैसे संदेशों का उपयोग किया जाता है; एचटीटीपी और इंटरनेट मीडिया प्रकार और वेब लिंकिंग जैसी अन्य इंटरनेट अवधारणाओं का पुन: उपयोग करता है (आरएफसी 5988)<ref name="rfc5988">{{cite IETF |rfc=5988 |title=वेब लिंकिंग|first1=Mark |last1=Nottingham |publisher=IETF |date=October 2010}}</ref>
-* [[सामग्री बातचीत]]
+* [[सामग्री बातचीत|सामग्री सामग्री सम्बन्ध]]
 * डाइजेस्ट एक्सेस ऑथेंटिकेशन
-* एचटीटीपी संपीड़न
+* एचटीटीपी उपयोग
-* एचटीटीपी/2 - IETF के हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (httpbis) वर्किंग ग्रुप द्वारा विकसित किया गया<ref>{{cite web |url=https://datatracker.ietf.org/wg/httpbis/charter/ |title=Hypertext Transfer Protocol Bis (httpbis) – Charter |publisher=IETF |year=2012}}</ref>
+* एचटीटीपी/2 - आईईटीएफ के हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (httpbis) वर्किंग ग्रुप द्वारा विकसित किया गया<ref>{{cite web |url=https://datatracker.ietf.org/wg/httpbis/charter/ |title=Hypertext Transfer Protocol Bis (httpbis) – Charter |publisher=IETF |year=2012}}</ref>
 * एचटीटीपी हेडर  फ़ील्ड की सूची
 * एचटीटीपी स्थिति कोड की सूची
-* प्रतिनिधित्वात्मक राज्य स्थानांतरण (REST)
+* प्रतिनिधित्वात्मक राज्य स्थानांतरण (रेस्ट)
 * [[भिन्न वस्तु]]
 * वेब कैश
@@ Line 468: / Line 468: @@
 {{reflist}}
 == बाहरी संबंध ==
-* {{Official website}}
+* [https://httpwg.org/specs/ Official website]
 * {{github|httpwg|IETF HTTP Working Group}}
 * {{cite web |url=https://www.w3.org/Protocols/History.html |title=Change History for HTTP |publisher=W3.org |access-date=2010-08-01}} A detailed technical history of HTTP.
 * {{cite web |url=https://www.w3.org/Protocols/DesignIssues.html |title=Design Issues for HTTP |publisher=W3.org |access-date=2010-08-01}} Design Issues by Berners-Lee when he was designing the protocol.
-{{Web browsers|fsp}}
-{{Semantic Web}}
-{{URI scheme}}
-{{Web interfaces}}
 {{Authority control}}
-[[Category: हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल | हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल ]] [[Category: अनुप्रयोग परत प्रोटोकॉल]] [[Category: 1991 में कंप्यूटर से संबंधित परिचय]] [[Category: इंटरनेट प्रोटोकॉल]] [[Category: नेटवर्क प्रोटोकॉल]] [[Category: वर्ल्ड वाइड वेब कंसोर्टियम मानक]]
-[[Category: Machine Translated Page]]
+[[Category:1991 में कंप्यूटर से संबंधित परिचय]]
+[[Category:Articles with hatnote templates targeting a nonexistent page]]
+[[Category:CS1 English-language sources (en)]]
+[[Category:Collapse templates]]
 [[Category:Created On 25/02/2023]]
+[[Category:Lua-based templates]]
+[[Category:Machine Translated Page]]
+[[Category:Navigational boxes| ]]
+[[Category:Navigational boxes without horizontal lists]]
+[[Category:Official website missing URL]]
+[[Category:Pages with reference errors]]
+[[Category:Pages with script errors]]
+[[Category:Short description with empty Wikidata description]]
+[[Category:Sidebars with styles needing conversion]]
+[[Category:Template documentation pages|Documentation/doc]]
+[[Category:Templates Vigyan Ready]]
+[[Category:Templates generating microformats]]
+[[Category:Templates that add a tracking category]]
+[[Category:Templates that are not mobile friendly]]
+[[Category:Templates that generate short descriptions]]
+[[Category:Templates using TemplateData]]
+[[Category:Wikipedia metatemplates]]


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 (1991)

Anonymous

Search