एचटीटीपी: 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

Revision as of 14:47, 2 March 2023

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

HTTP का विकास 1989 में सर्न में टिक बैरनर्स - ली द्वारा शुरू किया गया था और क्लाइंट के व्यवहार का वर्णन करने वाले एक साधारण दस्तावेज़ में सारांशित किया गया था और पहले HTTP प्रोटोकॉल संस्करण का उपयोग करने वाले सर्वर को 0.9 नाम दिया गया था। <रेफरी नाम = HTTP/0.9-विनिर्देश>Tim Berner-Lee (1991-01-01). "1991 में परिभाषित मूल HTTP". www.w3.org (in English). World Wide Web Consortium. Retrieved 2010-07-24.</ref>

HTTP प्रोटोकॉल का वह पहला संस्करण जल्द ही एक अधिक विस्तृत संस्करण में विकसित हुआ जो कि भविष्य के संस्करण 1.0 की ओर पहला मसौदा था।^[2]

टिप्पणियों के लिए शुरुआती HTTP अनुरोधों (RFCs) का विकास कुछ साल बाद शुरू हुआ और यह इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) और वर्ल्ड वाइड वेब कंसोर्टियम (W3C) द्वारा एक समन्वित प्रयास था, जिसका काम बाद में IETF में चला गया।

HTTP/1 को 1996 में अंतिम रूप दिया गया और पूरी तरह से प्रलेखित किया गया (संस्करण 1.0 के रूप में)। रेफरी> में RFC 1945. उस विनिर्देशन को तब HTTP/1.1 द्वारा समाप्त कर दिया गया था। </ref> यह 1997 में (संस्करण 1.1 के रूप में) विकसित हुआ और फिर इसके विनिर्देशों को 1999, 2014 और 2022 में अद्यतन किया गया। रेफरी>RFC 2068 (1997) अप्रचलित था RFC 2616 1999 में, जिसे अप्रचलित कर दिया गया था RFC 7230 2014 में, जिसे अप्रचलित किया गया था RFC 9110 2022 में।</ref> HTTPS नाम का इसका सुरक्षित संस्करण 80% से अधिक वेबसाइटों द्वारा उपयोग किया जाता है।^[3] HTTP / 2, 2015 में प्रकाशित, वायर पर HTTP के शब्दार्थ की अधिक कुशल अभिव्यक्ति प्रदान करता है। अब इसका उपयोग 41% वेबसाइटों द्वारा किया जाता है^[4] और लगभग सभी वेब ब्राउज़रों (97% से अधिक उपयोगकर्ताओं) द्वारा समर्थित है।^[5] यह एप्लिकेशन-लेयर प्रोटोकॉल बातचीत (ALPN) एक्सटेंशन का उपयोग करके परिवहन परत सुरक्षा (TLS) पर प्रमुख वेब सर्वरों द्वारा भी समर्थित है।^[6] जहां TLS 1.2 या नए की आवश्यकता है।^[7]^[8] HTTP/3, HTTP/2 का उत्तराधिकारी, 2022 में प्रकाशित हुआ था।^[9] अब इसका उपयोग 25% से अधिक वेबसाइटों द्वारा किया जाता है^[10] और कई वेब ब्राउज़रों (75% से अधिक उपयोगकर्ताओं) द्वारा समर्थित है।^[11] HTTP/3 अंतर्निहित ट्रांसपोर्ट प्रोटोकॉल के लिए प्रसारण नियंत्रण प्रोटोकॉल के अतिरिक्त QUIC का उपयोग करता है। HTTP/2 की तरह, यह प्रोटोकॉल के पिछले प्रमुख संस्करणों को अप्रचलित नहीं करता है। HTTP/3 के लिए समर्थन पहले Cloudflare और Google Chrome में जोड़ा गया था,^[12]^[13] और फ़ायरफ़ॉक्स में भी सक्षम है।^[14] HTTP / 3 में वास्तविक दुनिया के वेब पेजों के लिए कम विलंबता है, यदि सर्वर पर सक्षम किया गया है, तो HTTP / 2 की तुलना में तेज़ी से लोड होता है, और HTTP / 1.1 से भी तेज़, कुछ मामलों में HTTP / 1.1 से 3 × तेज़ (जो अभी भी है) सामान्यतः केवल सक्षम)।^[15]

तकनीकी सिंहावलोकन

File:Internet1.svg

HTTP स्कीम और वर्ल्ड वाइड वेब डोमेन नाम लेबल से शुरू होने वाला URL

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

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

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

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

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

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

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

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

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

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

इतिहास

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

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

CERN httpd 1990 में लाइव हुआ।^[22]^[23] उपयोग किए गए प्रोटोकॉल में केवल एक विधि थी, अर्थात् जीईटी, जो एक सर्वर से एक पृष्ठ का अनुरोध करेगी।^[24] सर्वर से प्रतिक्रिया हमेशा एक HTML पृष्ठ होती थी। <रेफरी नाम = HTTP/0.9-विनिर्देशन />

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

Version	Year introduced	Current status
HTTP/0.9	1991	Obsolete
HTTP/1.0	1996	Obsolete
HTTP/1.1	1997	Standard
HTTP/2	2015	Standard
HTTP/3	2022	Standard

एचटीटीपी/0.9

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

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

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

W3C HTTP वर्किंग ग्रुप

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

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

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

एचटीटीपी/1.0

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

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

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

एचटीटीपी/2

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

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

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

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

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

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

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

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

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

Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests caused by a client failing to properly encode the request-target.

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

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

^{[note 2]}

एचटीटीपी/3

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

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

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

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

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

HTTP डेटा एक्सचेंज

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

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

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

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

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

HTTP/1.0 में, जैसा कि RFC 1945 में कहा गया है, प्रतिक्रिया भेजे जाने के बाद TCP/IP कनेक्शन को हमेशा सर्वर द्वारा बंद कर दिया जाना चाहिए। ^{[note 3]}

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

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

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

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

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

एचटीटीपी/0.9

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

एचटीटीपी/1.0

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

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

एचटीटीपी/1.1

HTTP/1.1 पेश किया गया:

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

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

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

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

HTTP प्रमाणीकरण

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

HTTP चुनौती-प्रतिक्रिया प्रमाणीकरण योजनाओं के एक विस्तृत सेट के माध्यम से अभिगम नियंत्रण और प्रमाणीकरण के लिए एक सामान्य ढांचा प्रदान करता है, जिसका उपयोग सर्वर द्वारा क्लाइंट अनुरोध को चुनौती देने के लिए और क्लाइंट द्वारा प्रमाणीकरण जानकारी प्रदान करने के लिए किया जा सकता है।^[1] ऊपर वर्णित प्रमाणीकरण तंत्र HTTP प्रोटोकॉल से संबंधित हैं और क्लाइंट और सर्वर HTTP सॉफ़्टवेयर द्वारा प्रबंधित किए जाते हैं (यदि क्लाइंट को एक या अधिक वेब संसाधनों तक क्लाइंट पहुंच की अनुमति देने से पहले प्रमाणीकरण की आवश्यकता के लिए कॉन्फ़िगर किया गया है), और #HTTP एप्लिकेशन सत्र का उपयोग करने वाले वेब एप्लिकेशन द्वारा नहीं।

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

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

HTTP आवेदन सत्र

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

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

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

HTTP/1.1 अनुरोध संदेश

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

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

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

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

प्राप्त करें /छवियां/logo.png एचटीटीपी/1.1

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

होस्ट: www.example.com
स्वीकार-भाषा: en

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

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

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

अनुरोध के तरीके

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

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

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

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

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

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

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

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

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

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

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

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

सभी सामान्य-उद्देश्य वाले वेब सर्वरों को कम से कम GET और HEAD विधियों को लागू करने की आवश्यकता होती है, और अन्य सभी विधियों को विनिर्देश द्वारा वैकल्पिक माना जाता है।^[48]

Properties of request methods
Request method	RFC	Request has payload body	Response has payload body	Safe	Idempotent	Cacheable
GET	RFC 9110	Optional	Yes	Yes	Yes	Yes
HEAD	RFC 9110	Optional	No	Yes	Yes	Yes
POST	RFC 9110	Yes	Yes	No	No	Yes
PUT	RFC 9110	Yes	Yes	No	Yes	No
DELETE	RFC 9110	Optional	Yes	No	Yes	No
CONNECT	RFC 9110	Optional	Yes	No	No	No
OPTIONS	RFC 9110	Optional	Yes	Yes	Yes	No
TRACE	RFC 9110	No	Yes	Yes	Yes	No
PATCH	RFC 5789	Yes	Yes	No	No	No

सुरक्षित तरीके

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

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

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

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

निष्काम तरीके

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

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

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

प्राप्य तरीके

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

इसके विपरीत, PUT, DELETE, CONNECT, OPTIONS, TRACE, और PATCH के तरीके उपलब्ध नहीं हैं।

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

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

HTTP/1.1 प्रतिक्रिया संदेश

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

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

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

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

HTTP/1.1 200 ठीक है

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

सामग्री-प्रकार: पाठ/एचटीएमएल

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नीचे एक HTTP/1.1 क्लाइंट और एक HTTP/1.1 सर्वर के बीच एक नमूना HTTP लेनदेन है जो 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> शीर्ष लेख मान विभिन्न डोमेन की नामांकन प्रणाली नामों के बीच एक एकल आईपी पता साझा करने के बीच अंतर करता है, जिससे नाम-आधारित वर्चुअल होस्टिंग की अनुमति मिलती है। जबकि HTTP/1.0 में वैकल्पिक है, HTTP/1.1 में यह अनिवार्य है। (ए / (स्लैश) सामान्यतः एक वेबसर्वर डायरेक्टरी इंडेक्स|/index.html फ़ाइल लाएगा यदि कोई है।)

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

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

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

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

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

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

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

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

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

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

यह भी देखें

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

↑ In practice, these streams are used as multiple TCP/IP sub-connections to multiplex concurrent requests/responses, thus greatly reducing the number of real TCP/IP connections on server side, from 2..8 per client to 1, and allowing many more clients to be served at once.
↑ In 2022, HTTP/0.9 support has not been officially completely deprecated and is still present in many web servers and browsers (for server responses only), even if usually disabled. It is unclear how long it will take to decommission HTTP/0.9.
↑ Since late 1996, some developers of popular HTTP/1.0 browsers and servers (specially those who had planned support for HTTP/1.1 too), started to deploy (as an unofficial extension) a sort of keep-alive-mechanism (by using new HTTP headers) in order to keep the TCP/IP connection open for more than a request/response pair and so to speed up the exchange of multiple requests/responses.^[29]
↑ ^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 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org (in English). World Wide Web Consortium. Retrieved 2021-10-19.
↑ "वेबसाइटों के लिए डिफ़ॉल्ट प्रोटोकॉल 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.
↑ ^16.0 ^16.1 ^16.2 "Connections, Clients, and Servers". RFC 9110, HTTP Semantics. sec. 3.3. doi:10.17487/RFC9110. RFC 9110.
↑ "Overall Operation". RFC 1945. pp. 6–8. sec. 1.3. doi:10.17487/RFC1945. RFC 1945.
↑ ^18.0 ^18.1 ^18.2 "Connection Management: Establishment". RFC 9112, HTTP/1.1. sec. 9.1. doi:10.17487/RFC9112. RFC 9112.
↑ "Connection Management: Persistence". RFC 9112, HTTP/1.1. sec. 9.3. doi:10.17487/RFC9112. RFC 9112.
↑ "क्लासिक 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.
↑ ^25.0 ^25.1 Cite error: Invalid <ref> tag; no text was provided for refs named HTTP/0.9-specifications
↑ 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.
↑ ^29.0 ^29.1 David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections") (in English). O'Reilly Media, inc. ISBN 9781565925090. Retrieved 2021-10-18.
↑ "HTTP/1.1". Webcom.com Glossary entry. Archived from the original on 2001-11-21. Retrieved 2009-05-29.
↑ "एचटीटीपी-एनजी वर्किंग ग्रुप". 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.
↑ 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.
↑ ^43.0 ^43.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.
↑ ^48.0 ^48.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.
↑ ^56.0 ^56.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.

बाहरी संबंध

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

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

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

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

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

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

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

[63] 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/1.0-first-unofficial-draft-2] 2.0 ^2.1 Tim Berner-Lee (1992). "1992 में परिभाषित मूल HTTP". www.w3.org (in English). World Wide Web Consortium. Retrieved 2021-10-19.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[rfc7230-Appendix-A-38] "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-39] Matt Menke (2016-06-30). "बहिष्कृत करने और निकालने का इरादा: HTTP/0.9 समर्थन". groups.google.com (in English). Retrieved 2021-10-15.

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

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

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

[45] 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-47] 43.0 ^43.1 "Message format". RFC 9112: HTTP/1.1. sec. 2.1. doi:10.17487/RFC9112. RFC 9112.

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

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

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

[rfc9110-9.1-52] 48.0 ^48.1 "Methods: Overview". RFC 9110, HTTP Semantics. sec. 9.1. doi:10.17487/RFC9110. RFC 9110.

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

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

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

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

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

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

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

[oreilly-get-rails-60] 56.0 ^56.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.

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

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

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

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

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

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

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

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

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[note 1]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[note 2]

[39]

[40]

[41]

[note 3]

[42]

[note 4]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[note 5]

[note 6]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

@@ Line 23: / Line 23: @@
 {{IPstack}}
-हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP) वितरित, सहयोगी, [[हाइपरमीडिया]] सूचना प्रणाली के लिए [[इंटरनेट प्रोटोकॉल सूट]] मॉडल में एक [[अनुप्रयोग परत]] प्रोटोकॉल है।<ref name="rfc9110" />HTTP वर्ल्ड वाइड वेब के लिए डेटा संचार की नींव है, जहां [[हाइपरटेक्स्ट]] दस्तावेज़ों में अन्य संसाधनों के [[हाइपरलिंक]]्स शामिल होते हैं जिन्हें उपयोगकर्ता आसानी से एक्सेस कर सकता है, उदाहरण के लिए [[कम्प्यूटर का माउस]] क्लिक या वेब ब्राउज़र में स्क्रीन टैप करके।
+हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP) वितरित, सहयोगी, [[हाइपरमीडिया]] सूचना प्रणाली के लिए [[इंटरनेट प्रोटोकॉल सूट]] मॉडल में एक [[अनुप्रयोग परत]] प्रोटोकॉल है।<ref name="rfc9110" />HTTP वर्ल्ड वाइड वेब के लिए डेटा संचार की नींव है, जहां [[हाइपरटेक्स्ट]] दस्तावेज़ों में अन्य संसाधनों के [[हाइपरलिंक]]्स सम्मिलित  होते हैं जिन्हें उपयोगकर्ता आसानी से एक्सेस कर सकता है, उदाहरण के लिए [[कम्प्यूटर का माउस]] क्लिक या वेब ब्राउज़र में स्क्रीन टैप करके।
 HTTP का विकास 1989 में [[सर्न]] में [[ टिक बैरनर्स - ली ]] द्वारा शुरू किया गया था और क्लाइंट के व्यवहार का वर्णन करने वाले एक साधारण दस्तावेज़ में सारांशित किया गया था और पहले HTTP प्रोटोकॉल संस्करण का उपयोग करने वाले सर्वर को 0.9 नाम दिया गया था। <रेफरी नाम = HTTP/0.9-विनिर्देश>{{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>
@@ Line 35: / Line 35: @@
 [[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>
 HTTP / 2, 2015 में प्रकाशित, वायर पर HTTP के शब्दार्थ की अधिक कुशल अभिव्यक्ति प्रदान करता है। अब इसका उपयोग 41% वेबसाइटों द्वारा किया जाता है<ref name="HTTP2-usage-web-servers">{{Cite web|title=Usage Statistics of HTTP/2 for websites|url=https://w3techs.com/technologies/details/ce-http2|access-date=2022-12-02|website=w3techs.com}}</ref> और लगभग सभी वेब ब्राउज़रों (97% से अधिक उपयोगकर्ताओं) द्वारा समर्थित है।<ref name="HTTP2-Can-I-Use">{{Cite web|title=Can I use... Support tables for HTML5, CSS3, etc|url=https://caniuse.com/?search=http2|access-date=2022-10-16|website=caniuse.com}}</ref> यह [[ एप्लिकेशन-लेयर प्रोटोकॉल बातचीत ]] (ALPN) एक्सटेंशन का उपयोग करके [[परिवहन परत सुरक्षा]] (TLS) पर प्रमुख वेब सर्वरों द्वारा भी समर्थित है।<ref name="rfc7301">{{cite web|url=https://tools.ietf.org/html/rfc7301|title=ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) एप्लीकेशन-लेयर प्रोटोकॉल नेगोशिएशन एक्सटेंशन|date=July 2014|publisher=IETF|rfc=7301}}</ref> जहां TLS 1.2 या नए की आवश्यकता है।<ref>{{cite web|url=https://http2.github.io/http2-spec/#TLSUsage|title=Hypertext Transfer Protocol Version 2, Use of TLS Features|last1=Belshe|first1=M.|last2=Peon|first2=R.|access-date=2015-02-10|last3=Thomson|first3=M.|archive-date=2013-07-15|archive-url=https://web.archive.org/web/20130715004452/https://http2.github.io/http2-spec/#TLSUsage|url-status=dead}}</ref><ref>{{Cite web|first=David|last=Benjamin|title=Using TLS 1.3 with HTTP/2|url=https://tools.ietf.org/html/rfc8740.html|access-date=2020-06-02|website=tools.ietf.org|quote=This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.|language=en}}</ref>
-HTTP/3, HTTP/2 का उत्तराधिकारी, 2022 में प्रकाशित हुआ था।<ref>{{cite web |title=HTTP/3 |url=https://datatracker.ietf.org/doc/rfc9114/ |language=en-US |accessdate=2022-06-06}}</ref> अब इसका उपयोग 25% से अधिक वेबसाइटों द्वारा किया जाता है<ref name="HTTP3-usage-web-servers">{{Cite web|title=Usage Statistics of HTTP/3 for websites|url=https://w3techs.com/technologies/details/ce-http3|access-date=2022-10-16|website=w3techs.com}}</ref> और कई वेब ब्राउज़रों (75% से अधिक उपयोगकर्ताओं) द्वारा समर्थित है।<ref name="HTTP3-Can-I-Use">{{Cite web|title=Can I use... Support tables for HTML5, CSS3, etc|url=https://caniuse.com/?search=http3|access-date=2022-10-16|website=caniuse.com}}</ref> HTTP/3 अंतर्निहित ट्रांसपोर्ट प्रोटोकॉल के लिए [[ प्रसारण नियंत्रण प्रोटोकॉल ]] के बजाय [[QUIC]] का उपयोग करता है। HTTP/2 की तरह, यह प्रोटोकॉल के पिछले प्रमुख संस्करणों को अप्रचलित नहीं करता है। HTTP/3 के लिए समर्थन पहले [[Cloudflare]] और [[Google Chrome]] में जोड़ा गया था,<ref>{{cite web|url=https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/|title=Cloudflare, Google Chrome, and Firefox add HTTP/3 support|website=ZDNet|date=26 September 2019|access-date=27 September 2019|df=dmy-all|first=Catalin|last=Cimpanu}}</ref><ref>{{Cite web|url=https://blog.cloudflare.com/http3-the-past-present-and-future/|title=HTTP/3: the past, the present, and the future|date=2019-09-26|website=The Cloudflare Blog|language=en|access-date=2019-10-30}}</ref> और [[फ़ायरफ़ॉक्स]] में भी सक्षम है।<ref>{{cite web |url=https://community.cloudflare.com/t/firefox-nightly-supports-http-3/127778 |title=Firefox Nightly supports HTTP 3 - General - Cloudflare Community |date=2019-11-19 |access-date=2020-01-23}}</ref> HTTP / 3 में वास्तविक दुनिया के वेब पेजों के लिए कम विलंबता है, यदि सर्वर पर सक्षम किया गया है, तो HTTP / 2 की तुलना में तेज़ी से लोड होता है, और HTTP / 1.1 से भी तेज़, कुछ मामलों में HTTP / 1.1 से 3 × तेज़ (जो अभी भी है) आमतौर पर केवल सक्षम)।<ref>{{Cite web |title=HTTP/3 is Fast |url=https://requestmetrics.com/web-performance/http3-is-fast |access-date=2022-07-01 |website=Request Metrics |language=en}}</ref>
+HTTP/3, HTTP/2 का उत्तराधिकारी, 2022 में प्रकाशित हुआ था।<ref>{{cite web |title=HTTP/3 |url=https://datatracker.ietf.org/doc/rfc9114/ |language=en-US |accessdate=2022-06-06}}</ref> अब इसका उपयोग 25% से अधिक वेबसाइटों द्वारा किया जाता है<ref name="HTTP3-usage-web-servers">{{Cite web|title=Usage Statistics of HTTP/3 for websites|url=https://w3techs.com/technologies/details/ce-http3|access-date=2022-10-16|website=w3techs.com}}</ref> और कई वेब ब्राउज़रों (75% से अधिक उपयोगकर्ताओं) द्वारा समर्थित है।<ref name="HTTP3-Can-I-Use">{{Cite web|title=Can I use... Support tables for HTML5, CSS3, etc|url=https://caniuse.com/?search=http3|access-date=2022-10-16|website=caniuse.com}}</ref> HTTP/3 अंतर्निहित ट्रांसपोर्ट प्रोटोकॉल के लिए [[ प्रसारण नियंत्रण प्रोटोकॉल ]] के अतिरिक्त [[QUIC]] का उपयोग करता है। HTTP/2 की तरह, यह प्रोटोकॉल के पिछले प्रमुख संस्करणों को अप्रचलित नहीं करता है। HTTP/3 के लिए समर्थन पहले [[Cloudflare]] और [[Google Chrome]] में जोड़ा गया था,<ref>{{cite web|url=https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/|title=Cloudflare, Google Chrome, and Firefox add HTTP/3 support|website=ZDNet|date=26 September 2019|access-date=27 September 2019|df=dmy-all|first=Catalin|last=Cimpanu}}</ref><ref>{{Cite web|url=https://blog.cloudflare.com/http3-the-past-present-and-future/|title=HTTP/3: the past, the present, and the future|date=2019-09-26|website=The Cloudflare Blog|language=en|access-date=2019-10-30}}</ref> और [[फ़ायरफ़ॉक्स]] में भी सक्षम है।<ref>{{cite web |url=https://community.cloudflare.com/t/firefox-nightly-supports-http-3/127778 |title=Firefox Nightly supports HTTP 3 - General - Cloudflare Community |date=2019-11-19 |access-date=2020-01-23}}</ref> HTTP / 3 में वास्तविक दुनिया के वेब पेजों के लिए कम विलंबता है, यदि सर्वर पर सक्षम किया गया है, तो HTTP / 2 की तुलना में तेज़ी से लोड होता है, और HTTP / 1.1 से भी तेज़, कुछ मामलों में HTTP / 1.1 से 3 × तेज़ (जो अभी भी है) सामान्यतः केवल सक्षम)।<ref>{{Cite web |title=HTTP/3 is Fast |url=https://requestmetrics.com/web-performance/http3-is-fast |access-date=2022-07-01 |website=Request Metrics |language=en}}</ref>
 == तकनीकी सिंहावलोकन ==
 [[File:Internet1.svg|thumb|right|HTTP स्कीम और वर्ल्ड वाइड वेब डोमेन नाम लेबल से शुरू होने वाला [[URL]]]]HTTP क्लाइंट-सर्वर मॉडल में अनुरोध-प्रतिक्रिया प्रोटोकॉल के रूप में कार्य करता है। एक वेब ब्राउज़र, उदाहरण के लिए, 'क्लाइंट' हो सकता है, जबकि एक कंप्यूटर [[होस्ट (नेटवर्क)]] पर चलने वाली एक [[प्रक्रिया (कंप्यूटिंग)]], जिसका नाम वेब सर्वर है, एक या अधिक वेबसाइटें 'सर्वर' हो सकती हैं। क्लाइंट सर्वर को HTTP ''अनुरोध'' संदेश सबमिट करता है। सर्वर, जो क्लाइंट की ओर से 'संसाधन' जैसे [[HTML]] फ़ाइलें और अन्य सामग्री प्रदान करता है या अन्य कार्य करता है, क्लाइंट को 'प्रतिक्रिया' संदेश देता है। प्रतिक्रिया में अनुरोध के बारे में पूर्णता की स्थिति की जानकारी होती है और इसके संदेश के मुख्य भाग में अनुरोधित सामग्री भी हो सकती है।
-वेब ब्राउजर ''यूजर एजेंट'' (यूए) का एक उदाहरण है। अन्य प्रकार के [[उपयोगकर्ता एजेंट]] में खोज प्रदाताओं (वेब क्रॉलर), [[आवाज ब्राउज़र]], [[मोबाइल एप्लिकेशन]] और अन्य [[सॉफ़्टवेयर]] द्वारा उपयोग किए जाने वाले इंडेक्सिंग सॉफ़्टवेयर शामिल हैं जो वेब सामग्री तक पहुंचते हैं, उपभोग करते हैं या प्रदर्शित करते हैं।
+वेब ब्राउजर ''यूजर एजेंट'' (यूए) का एक उदाहरण है। अन्य प्रकार के [[उपयोगकर्ता एजेंट]] में खोज प्रदाताओं (वेब क्रॉलर), [[आवाज ब्राउज़र]], [[मोबाइल एप्लिकेशन]] और अन्य [[सॉफ़्टवेयर]] द्वारा उपयोग किए जाने वाले इंडेक्सिंग सॉफ़्टवेयर सम्मिलित  हैं जो वेब सामग्री तक पहुंचते हैं, उपभोग करते हैं या प्रदर्शित करते हैं।
-HTTP को क्लाइंट और सर्वर के बीच संचार को बेहतर बनाने या सक्षम करने के लिए मध्यवर्ती नेटवर्क तत्वों को अनुमति देने के लिए डिज़ाइन किया गया है। उच्च-ट्रैफ़िक वेबसाइटें अक्सर वेब कैश सर्वर से लाभान्वित होती हैं जो प्रतिक्रिया समय को बेहतर बनाने के लिए [[अपस्ट्रीम सर्वर]] की ओर से सामग्री वितरित करती हैं। वेब ब्राउज़र पहले से एक्सेस किए गए वेब संसाधनों को कैश करते हैं और नेटवर्क ट्रैफ़िक को कम करने के लिए, जब भी संभव हो, उनका पुन: उपयोग करते हैं। निजी नेटवर्क सीमाओं पर HTTP [[प्रॉक्सी सर्वर]] बाहरी सर्वर के साथ संदेशों को रिले करके वैश्विक रूप से निष्क्रिय पते के बिना ग्राहकों के लिए संचार की सुविधा प्रदान कर सकते हैं।
+HTTP को क्लाइंट और सर्वर के बीच संचार को बेहतर बनाने या सक्षम करने के लिए मध्यवर्ती नेटवर्क तत्वों को अनुमति देने के लिए डिज़ाइन किया गया है। उच्च-ट्रैफ़िक वेबसाइटें प्रायः वेब कैश सर्वर से लाभान्वित होती हैं जो प्रतिक्रिया समय को बेहतर बनाने के लिए [[अपस्ट्रीम सर्वर]] की ओर से सामग्री वितरित करती हैं। वेब ब्राउज़र पहले से एक्सेस किए गए वेब संसाधनों को कैश करते हैं और नेटवर्क ट्रैफ़िक को कम करने के लिए, जब भी संभव हो, उनका पुन: उपयोग करते हैं। निजी नेटवर्क सीमाओं पर HTTP [[प्रॉक्सी सर्वर]] बाहरी सर्वर के साथ संदेशों को रिले करके वैश्विक रूप से निष्क्रिय पते के बिना ग्राहकों के लिए संचार की सुविधा प्रदान कर सकते हैं।
 इंटरमीडिएट एचटीटीपी नोड्स (प्रॉक्सी सर्वर, वेब कैश आदि) को उनके कार्यों को पूरा करने की अनुमति देने के लिए, एचटीटीपी [[HTTP हेडर फ़ील्ड की सूची]] (एचटीटीपी अनुरोधों/प्रतिक्रियाओं में पाई जाती है) को प्रबंधित किया जाता है [[ हॉप-बाय-हॉप परिवहन ]]|हॉप-बाय-हॉप जबकि अन्य HTTP शीर्षलेख [[एंड-टू-एंड सिद्धांत]] | एंड-टू-एंड प्रबंधित हैं (केवल स्रोत क्लाइंट और लक्ष्य वेब सर्वर द्वारा प्रबंधित)।
-HTTP एक एप्लिकेशन लेयर प्रोटोकॉल है जिसे इंटरनेट प्रोटोकॉल सूट के ढांचे के भीतर डिज़ाइन किया गया है। इसकी परिभाषा एक अंतर्निहित और विश्वसनीय [[ ट्रांसपोर्ट परत ]] प्रोटोकॉल मानती है,<ref name="rfc9110-3.3" />इस प्रकार ट्रांसमिशन कंट्रोल प्रोटोकॉल (टीसीपी) का आमतौर पर उपयोग किया जाता है। हालाँकि, HTTP को उपयोगकर्ता [[डेटाग्राम प्रोटेकॉलका उपयोग करें]]UDP) जैसे अविश्वसनीय प्रोटोकॉल का उपयोग करने के लिए अनुकूलित किया जा सकता है, उदाहरण के लिए [[HTTPU]] और [[सरल सेवा डिस्कवरी प्रोटोकॉल]] (SSDP) में।
+HTTP एक एप्लिकेशन लेयर प्रोटोकॉल है जिसे इंटरनेट प्रोटोकॉल सूट के ढांचे के भीतर डिज़ाइन किया गया है। इसकी परिभाषा एक अंतर्निहित और विश्वसनीय [[ ट्रांसपोर्ट परत ]] प्रोटोकॉल मानती है,<ref name="rfc9110-3.3" />इस प्रकार ट्रांसमिशन कंट्रोल प्रोटोकॉल (टीसीपी) का सामान्यतः उपयोग किया जाता है। हालाँकि, HTTP को उपयोगकर्ता [[डेटाग्राम प्रोटेकॉलका उपयोग करें]]UDP) जैसे अविश्वसनीय प्रोटोकॉल का उपयोग करने के लिए अनुकूलित किया जा सकता है, उदाहरण के लिए [[HTTPU]] और [[सरल सेवा डिस्कवरी प्रोटोकॉल]] (SSDP) में।
 [[यूनिफॉर्म रिसोर्स पहचानकर्ता]] (URI's) योजनाओं http और [[https]] का उपयोग करके, [[यूनिफ़ॉर्म रिसोर्स लोकेटर]]्स (URLs) द्वारा वेब संसाधनों की पहचान की जाती है और नेटवर्क पर स्थित किया जाता है। जैसा कि परिभाषित किया गया है {{IETF RFC|3986}}, URI को HTML दस्तावेज़ों में हाइपरलिंक के रूप में एन्कोड किया गया है, ताकि आपस में जुड़े हाइपरटेक्स्ट दस्तावेज़ बनाए जा सकें।
 HTTP/1.0 में प्रत्येक संसाधन अनुरोध के लिए एक ही सर्वर के लिए एक अलग [[कनेक्शन-उन्मुख संचार]] किया जाता है।<ref name="rfc1945-1.3">{{cite IETF |rfc=1945 |sectionname=Overall Operation |section=1.3 |title=RFC 1945|pages=6–8}}</ref>
-एचटीटीपी/1.1 में इसके बजाय एक टीसीपी कनेक्शन का पुन: उपयोग कई संसाधन अनुरोध (यानी एचटीएमएल पेज, फ्रेम, इमेज, [[क्लाइंट-साइड स्क्रिप्टिंग]], [[व्यापक शैली पत्रक]] आदि) करने के लिए किया जा सकता है।<ref name="rfc9112-9.1" /><ref name="rfc9112-9.3">{{cite IETF |rfc=9112 |sectionname=Connection Management: Persistence |section=9.3 |title=RFC 9112, HTTP/1.1}}</ref>
+एचटीटीपी/1.1 में इसके अतिरिक्त एक टीसीपी कनेक्शन का पुन: उपयोग कई संसाधन अनुरोध (यानी एचटीएमएल पेज, फ्रेम, इमेज, [[क्लाइंट-साइड स्क्रिप्टिंग]], [[व्यापक शैली पत्रक]] आदि) करने के लिए किया जा सकता है।<ref name="rfc9112-9.1" /><ref name="rfc9112-9.3">{{cite IETF |rfc=9112 |sectionname=Connection Management: Persistence |section=9.3 |title=RFC 9112, HTTP/1.1}}</ref>
 HTTP/1.1 संचार इसलिए कम [[विलंबता (इंजीनियरिंग)]] का अनुभव करते हैं क्योंकि टीसीपी कनेक्शन की स्थापना विशेष रूप से उच्च यातायात स्थितियों के तहत काफी ओवरहेड प्रस्तुत करती है।<ref>{{cite web |url=https://www.w3.org/Protocols/Classic.html |title=क्लासिक HTTP दस्तावेज़|publisher=W3.org |date=1998-05-14 |access-date=2010-08-01}}</ref>
 एचटीटीपी/2 पिछले एचटीटीपी/1.1 का एक संशोधन है ताकि समान क्लाइंट-सर्वर मॉडल और समान प्रोटोकॉल विधियों को बनाए रखा जा सके लेकिन इन अंतरों के क्रम में:
-* टेक्स्ट के बजाय मेटाडेटा (HTTP हेडर) के एक संकुचित बाइनरी प्रतिनिधित्व का उपयोग करने के लिए, ताकि हेडर को बहुत कम जगह की आवश्यकता हो;
+* टेक्स्ट के अतिरिक्त मेटाडेटा (HTTP हेडर) के एक संकुचित बाइनरी प्रतिनिधित्व का उपयोग करने के लिए, ताकि हेडर को बहुत कम जगह की आवश्यकता हो;
-* 2 से 8 टीसीपी/आईपी कनेक्शन के बजाय प्रत्येक एक्सेस किए गए सर्वर डोमेन के लिए एक टीसीपी/[[इंटरनेट प्रोटोकॉल]] (आमतौर पर [[ कूटलेखन ]]) कनेक्शन का उपयोग करने के लिए;
+* 2 से 8 टीसीपी/आईपी कनेक्शन के अतिरिक्त प्रत्येक एक्सेस किए गए सर्वर डोमेन के लिए एक टीसीपी/[[इंटरनेट प्रोटोकॉल]] (सामान्यतः [[ कूटलेखन ]]) कनेक्शन का उपयोग करने के लिए;
 * प्रति टीसीपी / आईपी कनेक्शन में एक या एक से अधिक द्विदिश धाराओं का उपयोग करने के लिए जिसमें एचओएलबी ([[हेड-ऑफ-लाइन ब्लॉकिंग]]) की समस्या को हल करने के लिए HTTP अनुरोधों और प्रतिक्रियाओं को तोड़ दिया जाता है और छोटे पैकेटों में प्रेषित किया जाता है। {{refn|group=note|In practice, these streams are used as multiple TCP/IP sub-connections to [[Multiplexing|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.}}
 * जब भी नया डेटा उपलब्ध हो, सर्वर एप्लिकेशन को ग्राहकों को डेटा भेजने की अनुमति देने के लिए एक पुश क्षमता जोड़ने के लिए (ग्राहकों को [[मतदान (कंप्यूटर विज्ञान)]] विधियों का उपयोग करके सर्वर से समय-समय पर नए डेटा का अनुरोध करने के लिए मजबूर किए बिना)।<ref name="rfc9113-2">{{cite IETF |rfc=7540 |section=2 |sectionname=HTTP/2 Protocol Overview| title=RFC 9113, HTTP/2)}}</ref>
 HTTP/2 संचार इसलिए बहुत कम विलंबता का अनुभव करते हैं और, ज्यादातर मामलों में, HTTP/1.1 संचार से भी अधिक गति।
-एचटीटीपी/3 टीसीपी/आईपी कनेक्शन के बजाय क्विक + यूडीपी ट्रांसपोर्ट प्रोटोकॉल का उपयोग करने के लिए पिछले एचटीटीपी/2 का एक संशोधन है, संचार की औसत गति में थोड़ा सुधार करने और टीसीपी/आईपी कनेक्शन की सामयिक (बहुत दुर्लभ) समस्या से बचने के लिए [[ टीसीपी भीड़ नियंत्रण ]] जो अपनी सभी धाराओं के डेटा प्रवाह को अस्थायी रूप से ब्लॉक या धीमा कर सकता है ('हेड ऑफ लाइन ब्लॉकिंग'' का दूसरा रूप)।
+एचटीटीपी/3 टीसीपी/आईपी कनेक्शन के अतिरिक्त क्विक + यूडीपी ट्रांसपोर्ट प्रोटोकॉल का उपयोग करने के लिए पिछले एचटीटीपी/2 का एक संशोधन है, संचार की औसत गति में थोड़ा सुधार करने और टीसीपी/आईपी कनेक्शन की सामयिक (बहुत दुर्लभ) समस्या से बचने के लिए [[ टीसीपी भीड़ नियंत्रण ]] जो अपनी सभी धाराओं के डेटा प्रवाह को अस्थायी रूप से ब्लॉक या धीमा कर सकता है ('हेड ऑफ लाइन ब्लॉकिंग'' का दूसरा रूप)।
 == इतिहास ==
@@ Line 96: / Line 96: @@
 : 1991 में, HTTP का पहला प्रलेखित आधिकारिक संस्करण एक सादे दस्तावेज़ के रूप में लिखा गया था, जो 700 शब्दों से कम लंबा था, और इस संस्करण को HTTP/0.9 नाम दिया गया था। HTTP/0.9 केवल GET विधि का समर्थन करता है, क्लाइंट को सर्वर से केवल HTML दस्तावेज़ प्राप्त करने की अनुमति देता है, लेकिन किसी अन्य फ़ाइल स्वरूपों या सूचना अपलोड का समर्थन नहीं करता है।<ref name= HTTP/0.9-specifications />
 एचटीटीपी/1.0-ड्राफ्ट
-: 1992 के बाद से, इसके अगले पूर्ण संस्करण के लिए मूल प्रोटोकॉल के विकास को निर्दिष्ट करने के लिए एक नया दस्तावेज़ लिखा गया था। यह 0.9 संस्करण की सरल अनुरोध विधि और क्लाइंट HTTP संस्करण को शामिल करने वाले पूर्ण GET अनुरोध दोनों का समर्थन करता है। यह कई अनौपचारिक HTTP/1.0 ड्राफ्ट में से पहला था जो HTTP/1.0 पर अंतिम कार्य से पहले था।<ref name= HTTP/1.0-first-unofficial-draft />
+: 1992 के बाद से, इसके अगले पूर्ण संस्करण के लिए मूल प्रोटोकॉल के विकास को निर्दिष्ट करने के लिए एक नया दस्तावेज़ लिखा गया था। यह 0.9 संस्करण की सरल अनुरोध विधि और क्लाइंट HTTP संस्करण को सम्मिलित  करने वाले पूर्ण GET अनुरोध दोनों का समर्थन करता है। यह कई अनौपचारिक HTTP/1.0 ड्राफ्ट में से पहला था जो HTTP/1.0 पर अंतिम कार्य से पहले था।<ref name= HTTP/1.0-first-unofficial-draft />
 W3C HTTP वर्किंग ग्रुप
 : यह तय करने के बाद कि HTTP प्रोटोकॉल की नई विशेषताओं की आवश्यकता थी और उन्हें टिप्पणियों के लिए आधिकारिक अनुरोध के रूप में पूरी तरह से प्रलेखित किया जाना था, 1995 की शुरुआत में मानकीकरण के उद्देश्य से HTTP वर्किंग ग्रुप (HTTP WG, [[डेव रैगेट]] के नेतृत्व में) का गठन किया गया था और विस्तारित संचालन, विस्तारित बातचीत, समृद्ध मेटा-सूचना के साथ प्रोटोकॉल का विस्तार करें, एक सुरक्षा प्रोटोकॉल से जुड़ा हुआ है जो अतिरिक्त तरीकों और HTTP हेडर फ़ील्ड की सूची जोड़कर अधिक कुशल हो गया है।<ref name="raggettprofile">{{Cite web |last=Raggett |first=Dave |title=डेव रैगेट का बायो|url=https://www.w3.org/People/Raggett/profile.html|publisher=World Wide Web Consortium |access-date=11 June 2010}}</ref><ref>{{cite web |last1=Raggett |first1=Dave |title=हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल वर्किंग ग्रुप|url=https://www.w3.org/Arena/webworld/httpwgcharter.html |publisher=World Wide Web Consortium |access-date=29 September 2010 |first2=Tim |last2=Berners-Lee}}</ref>
@@ Line 103: / Line 103: @@
 एचटीटीपी/1.0
 : मई 1996 में, {{IETF RFC|1945}} पिछले 4 वर्षों में पूर्व-मानक HTTP/1.0-ड्राफ्ट के रूप में उपयोग किए गए अंतिम HTTP/1.0 संशोधन के रूप में प्रकाशित किया गया था जो पहले से ही कई वेब ब्राउज़रों और वेब सर्वरों द्वारा उपयोग किया जा चुका था।
-: 1996 की शुरुआत में डेवलपर्स ने आगामी HTTP/1.1 विनिर्देशों के ड्राफ्ट का उपयोग करके अपने उत्पादों में HTTP/1.0 प्रोटोकॉल के अनौपचारिक विस्तार (यानी कनेक्शन को जीवित रखना, आदि) को शामिल करना शुरू कर दिया।<ref name="HTTP-Persistent-Connections"/>एचटीटीपी/1.1
+: 1996 की शुरुआत में डेवलपर्स ने आगामी HTTP/1.1 विनिर्देशों के ड्राफ्ट का उपयोग करके अपने उत्पादों में HTTP/1.0 प्रोटोकॉल के अनौपचारिक विस्तार (यानी कनेक्शन को जीवित रखना, आदि) को सम्मिलित  करना शुरू कर दिया।<ref name="HTTP-Persistent-Connections"/>एचटीटीपी/1.1
 :1996 की शुरुआत से, प्रमुख वेब ब्राउज़र और वेब सर्वर डेवलपर्स ने भी पूर्व-मानक HTTP/1.1 ड्राफ्ट विनिर्देशों द्वारा निर्दिष्ट नई सुविधाओं को लागू करना शुरू कर दिया। ब्राउज़रों और सर्वरों के नए संस्करणों को एंड-यूज़र अपनाने की गति तेज़ थी। मार्च 1996 में, एक वेब होस्टिंग कंपनी ने बताया कि इंटरनेट पर उपयोग में आने वाले 40% से अधिक ब्राउज़रों ने [[वर्चुअल होस्टिंग]] को सक्षम करने के लिए नए HTTP/1.1 हेडर होस्ट का उपयोग किया। उसी वेब होस्टिंग कंपनी ने बताया कि जून 1996 तक, उनके सर्वर तक पहुँचने वाले सभी ब्राउज़रों में से 65% पूर्व-मानक HTTP/1.1 अनुरूप थे।<ref>{{Cite web |work=Webcom.com Glossary entry |title=HTTP/1.1 |url=https://www.webcom.com/glossary/http1.1.shtml |archive-url=http://webarchive.loc.gov/all/20011121001051/https://www.webcom.com/glossary/http1.1.shtml |url-status=dead |archive-date=2001-11-21 |access-date=2009-05-29 }}</ref>
 : जनवरी 1997 में, {{IETF RFC|2068}} आधिकारिक तौर पर HTTP/1.1 विनिर्देशों के रूप में जारी किया गया था।
-: जून 1999 में, {{IETF RFC|2616}} पिछले (अप्रचलित) HTTP/1.1 विनिर्देशों के आधार पर सभी सुधारों और अद्यतनों को शामिल करने के लिए जारी किया गया था।
+: जून 1999 में, {{IETF RFC|2616}} पिछले (अप्रचलित) HTTP/1.1 विनिर्देशों के आधार पर सभी सुधारों और अद्यतनों को सम्मिलित  करने के लिए जारी किया गया था।
 ;W3C HTTP-NG वर्किंग ग्रुप
 :पिछले एचटीटीपी वर्किंग ग्रुप की 1995 की पुरानी योजना को फिर से शुरू करते हुए, 1997 में एचटीटीपी-एनजी (एचटीटीपी न्यू जनरेशन) नामक एक नया एचटीटीपी प्रोटोकॉल विकसित करने के लिए एक एचटीटीपी-एनजी वर्किंग ग्रुप बनाया गया था। एक एकल टीसीपी/आईपी कनेक्शन के अंदर एचटीटीपी लेनदेन के [[ बहुसंकेतन ]] का उपयोग करने के लिए नए प्रोटोकॉल के लिए कुछ प्रस्ताव/ड्राफ्ट तैयार किए गए थे, लेकिन 1999 में, समूह ने आईईटीएफ को तकनीकी समस्याओं को पास करते हुए अपनी गतिविधि बंद कर दी।<ref name="HTTP-NG-Working-Group">{{Cite web|url=https://www.w3.org/Protocols/HTTP-NG/|title=एचटीटीपी-एनजी वर्किंग ग्रुप|website=www.w3.org|publisher=World Wide Web Consortium|year=1997|access-date=2021-10-19|language=en|author=}}</ref>
@@ Line 134: / Line 134: @@
 :* यह इतना सरल है कि एक RFC दस्तावेज़ कभी नहीं लिखा गया था (केवल मूल दस्तावेज़ है);<ref name= HTTP/0.9-specifications />
 :* इसमें कोई एचटीटीपी हेडर नहीं है और कई अन्य विशेषताओं का अभाव है जो आजकल न्यूनतम सुरक्षा कारणों से आवश्यक हैं;
-:* यह 1999..2000 (HTTP/1.0 और HTTP/1.1 के कारण) से व्यापक नहीं हुआ है और आमतौर पर केवल कुछ बहुत पुराने नेटवर्क हार्डवेयर, यानी [[राउटर (कंप्यूटिंग)]], आदि द्वारा उपयोग किया जाता है।
+:* यह 1999..2000 (HTTP/1.0 और HTTP/1.1 के कारण) से व्यापक नहीं हुआ है और सामान्यतः केवल कुछ बहुत पुराने नेटवर्क हार्डवेयर, यानी [[राउटर (कंप्यूटिंग)]], आदि द्वारा उपयोग किया जाता है।
 :{{refn|group=note|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.}}
 एचटीटीपी/3
@@ Line 150: / Line 150: @@
 == HTTP डेटा एक्सचेंज ==
-HTTP एक [[स्टेटलेस प्रोटोकॉल]] एप्लिकेशन-लेवल प्रोटोकॉल है और इसे क्लाइंट और सर्वर के बीच डेटा के आदान-प्रदान के लिए एक विश्वसनीय नेटवर्क ट्रांसपोर्ट कनेक्शन की आवश्यकता होती है।<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> HTTP/2 में, एक TCP/IP कनेक्शन और कई प्रोटोकॉल चैनल का उपयोग किया जाता है। HTTP/3 में, यूडीपी पर एप्लिकेशन ट्रांसपोर्ट प्रोटोकॉल क्विक का उपयोग किया जाता है।
+HTTP एक [[स्टेटलेस प्रोटोकॉल]] एप्लिकेशन-लेवल प्रोटोकॉल है और इसे क्लाइंट और सर्वर के बीच डेटा के आदान-प्रदान के लिए एक विश्वसनीय नेटवर्क ट्रांसपोर्ट कनेक्शन की आवश्यकता होती है।<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> HTTP/2 में, एक TCP/IP कनेक्शन और कई प्रोटोकॉल चैनल का उपयोग किया जाता है। HTTP/3 में, यूडीपी पर एप्लिकेशन ट्रांसपोर्ट प्रोटोकॉल क्विक का उपयोग किया जाता है।
 === कनेक्शन के माध्यम से अनुरोध और प्रतिक्रिया संदेश ===
-अनुरोध-प्रतिक्रिया | अनुरोध-प्रतिक्रिया संदेशों के अनुक्रम के माध्यम से डेटा का आदान-प्रदान किया जाता है, जो एक [[सत्र परत]] परिवहन कनेक्शन द्वारा आदान-प्रदान किया जाता है।<ref name="rfc9110-3.3" />एक HTTP क्लाइंट प्रारंभ में एक कनेक्शन (वास्तविक या वर्चुअल) स्थापित करने वाले सर्वर से कनेक्ट करने का प्रयास करता है। उस पोर्ट पर सुनने वाला HTTP(S) सर्वर कनेक्शन स्वीकार करता है और फिर क्लाइंट के अनुरोध संदेश की प्रतीक्षा करता है। क्लाइंट सर्वर को अपना अनुरोध भेजता है। अनुरोध प्राप्त होने पर, सर्वर एक HTTP प्रतिक्रिया संदेश वापस भेजता है (यदि आवश्यक हो तो हेडर प्लस बॉडी)। इस संदेश का मुख्य भाग आमतौर पर अनुरोधित संसाधन है, हालांकि एक त्रुटि संदेश या अन्य जानकारी भी लौटाई जा सकती है। किसी भी समय (कई कारणों से) क्लाइंट या सर्वर कनेक्शन बंद कर सकता है। सर्वर या क्लाइंट को भेजे गए अंतिम अनुरोध/प्रतिक्रिया संदेश में एक या अधिक HTTP शीर्षलेखों का उपयोग करके आमतौर पर एक कनेक्शन बंद करना अग्रिम रूप से विज्ञापित किया जाता है।<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" />एक HTTP क्लाइंट प्रारंभ में एक कनेक्शन (वास्तविक या वर्चुअल) स्थापित करने वाले सर्वर से कनेक्ट करने का प्रयास करता है। उस पोर्ट पर सुनने वाला HTTP(S) सर्वर कनेक्शन स्वीकार करता है और फिर क्लाइंट के अनुरोध संदेश की प्रतीक्षा करता है। क्लाइंट सर्वर को अपना अनुरोध भेजता है। अनुरोध प्राप्त होने पर, सर्वर एक HTTP प्रतिक्रिया संदेश वापस भेजता है (यदि आवश्यक हो तो हेडर प्लस बॉडी)। इस संदेश का मुख्य भाग सामान्यतः अनुरोधित संसाधन है, हालांकि एक त्रुटि संदेश या अन्य जानकारी भी लौटाई जा सकती है। किसी भी समय (कई कारणों से) क्लाइंट या सर्वर कनेक्शन बंद कर सकता है। सर्वर या क्लाइंट को भेजे गए अंतिम अनुरोध/प्रतिक्रिया संदेश में एक या अधिक HTTP शीर्षलेखों का उपयोग करके सामान्यतः एक कनेक्शन बंद करना अग्रिम रूप से विज्ञापित किया जाता है।<ref name="rfc9112-9.1">{{cite IETF |rfc=9112 |sectionname=Connection Management: Establishment |section=9.1 |title=RFC 9112, HTTP/1.1}}</ref>
 === लगातार कनेक्शन ===
 {{Main|HTTP persistent connection}}
@@ Line 160: / Line 160: @@
 HTTP/1.0 में, जैसा कि RFC 1945 में कहा गया है, प्रतिक्रिया भेजे जाने के बाद TCP/IP कनेक्शन को हमेशा सर्वर द्वारा बंद कर दिया जाना चाहिए। {{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>}}
-HTTP/1.1 में एक कीप-अलाइव-मैकेनिज्म आधिकारिक तौर पर पेश किया गया था ताकि एक से अधिक अनुरोध/प्रतिक्रिया के लिए एक कनेक्शन का पुन: उपयोग किया जा सके। इस तरह के लगातार कनेक्शन अनुरोध विलंबता (इंजीनियरिंग) को स्पष्ट रूप से कम कर देते हैं क्योंकि क्लाइंट को ट्रांसमिशन कंट्रोल प्रोटोकॉल # कनेक्शन स्थापना | टीसीपी 3-वे-हैंडशेक कनेक्शन के पहले अनुरोध के बाद फिर से बातचीत करने की आवश्यकता नहीं होती है। एक और सकारात्मक पक्ष प्रभाव यह है कि, सामान्य तौर पर, टीसीपी के टीसीपी कंजेशन कंट्रोल # स्लो स्टार्ट | स्लो-स्टार्ट-मैकेनिज्म के कारण कनेक्शन समय के साथ तेज हो जाता है।
+HTTP/1.1 में एक कीप-अलाइव-मैकेनिज्म आधिकारिक तौर पर पेश किया गया था ताकि एक से अधिक अनुरोध/प्रतिक्रिया के लिए एक कनेक्शन का पुन: उपयोग किया जा सके। इस तरह के लगातार कनेक्शन अनुरोध विलंबता (इंजीनियरिंग) को स्पष्ट रूप से कम कर देते हैं क्योंकि क्लाइंट को ट्रांसमिशन कंट्रोल प्रोटोकॉल # कनेक्शन स्थापना | टीसीपी 3-वे-हैंडशेक कनेक्शन के पहले अनुरोध के बाद फिर से बातचीत करने की आवश्यकता नहीं होती है। एक और सकारात्मक पक्ष प्रभाव यह है कि, सामान्यतः, टीसीपी के टीसीपी कंजेशन कंट्रोल # स्लो स्टार्ट | स्लो-स्टार्ट-मैकेनिज्म के कारण कनेक्शन समय के साथ तेज हो जाता है।
 HTTP / 1.1 ने [[HTTP पाइपलाइनिंग]] को भी जोड़ा ताकि ग्राहकों को प्रत्येक प्रतिक्रिया की प्रतीक्षा करने से पहले कई अनुरोध भेजने की अनुमति देकर लगातार कनेक्शन का उपयोग करते समय अंतराल को कम किया जा सके। इस अनुकूलन को कभी भी वास्तव में सुरक्षित नहीं माना गया क्योंकि कुछ वेब सर्वर और कई प्रॉक्सी सर्वर, विशेष रूप से क्लाइंट और सर्वर के बीच इंटरनेट/[[इंट्रानेट]] में रखे गए पारदर्शी प्रॉक्सी सर्वर, पाइपलाइन किए गए अनुरोधों को ठीक से संभाल नहीं पाए (उन्होंने दूसरों को छोड़कर केवल पहला अनुरोध पूरा किया, उन्होंने बंद कर दिया कनेक्शन क्योंकि उन्होंने पहले अनुरोध के बाद अधिक डेटा देखा था या कुछ प्रॉक्सी ने प्रतिक्रियाओं को आदेश से बाहर कर दिया था)। इसके अलावा केवल HEAD और कुछ GET अनुरोध (अर्थात वास्तविक फ़ाइल अनुरोधों तक सीमित और कमांड के रूप में उपयोग किए जाने वाले क्वेरी स्ट्रिंग के बिना URL के साथ) को #Safe विधियों और #Idempotent विधियों मोड में पाइपलाइन किया जा सकता है। पाइपलाइनिंग को सक्षम करके शुरू की गई समस्याओं से कई वर्षों तक संघर्ष करने के बाद, HTTP/2 को अपनाने की घोषणा के कारण इस सुविधा को पहले अक्षम कर दिया गया और फिर अधिकांश ब्राउज़रों से भी हटा दिया गया।
@@ Line 178: / Line 178: @@
 :* नए हेडर कैश्ड संसाधनों की सशर्त पुनर्प्राप्ति को बेहतर ढंग से प्रबंधित करने के लिए।
 :* खंडित स्थानांतरण एन्कोडिंग सामग्री को टुकड़ों में प्रवाहित करने की अनुमति देने के लिए विश्वसनीय रूप से भेजने के लिए भले ही सर्वर को इसकी लंबाई पहले से पता न हो (अर्थात क्योंकि यह गतिशील रूप से उत्पन्न होता है, आदि)।
-: * [[बाइट सर्विंग]], जहां एक ग्राहक संसाधन के केवल एक या एक से अधिक भागों (बाइट्स की रेंज) का अनुरोध कर सकता है (यानी पहला भाग, बीच में एक हिस्सा या पूरी सामग्री के अंत में, आदि) और सर्वर आमतौर पर केवल अनुरोधित भाग भेजता है। यह एक बाधित डाउनलोड को फिर से शुरू करने के लिए उपयोगी होता है (जब फ़ाइल वास्तव में बड़ी होती है), जब किसी सामग्री का केवल एक हिस्सा दिखाना होता है या ब्राउज़र द्वारा पहले से ही दिखाई देने वाले हिस्से में गतिशील रूप से जोड़ा जाता है (यानी केवल पहली या निम्नलिखित एन टिप्पणियाँ) एक वेब पेज) खाली समय, बैंडविड्थ और सिस्टम संसाधनों आदि के लिए।
+: * [[बाइट सर्विंग]], जहां एक ग्राहक संसाधन के केवल एक या एक से अधिक भागों (बाइट्स की रेंज) का अनुरोध कर सकता है (यानी पहला भाग, बीच में एक हिस्सा या पूरी सामग्री के अंत में, आदि) और सर्वर सामान्यतः केवल अनुरोधित भाग भेजता है। यह एक बाधित डाउनलोड को फिर से शुरू करने के लिए उपयोगी होता है (जब फ़ाइल वास्तव में बड़ी होती है), जब किसी सामग्री का केवल एक हिस्सा दिखाना होता है या ब्राउज़र द्वारा पहले से ही दिखाई देने वाले हिस्से में गतिशील रूप से जोड़ा जाता है (यानी केवल पहली या निम्नलिखित एन टिप्पणियाँ) एक वेब पेज) खाली समय, बैंडविड्थ और सिस्टम संसाधनों आदि के लिए।
 ; एचटीटीपी/2, एचटीटीपी/3
 : एचटीटीपी/2 और एचटीटीपी/3 दोनों में एचटीटीपी/1.1 की उपरोक्त विशेषताएं रखी गई हैं।
@@ Line 203: / Line 203: @@
 === अनुरोध सिंटैक्स ===
-क्लाइंट सर्वर को अनुरोध संदेश भेजता है, जिसमें निम्न शामिल हैं:<ref name="rfc9112-2.1">{{cite IETF |rfc=9112 |sectionname=Message format |section=2.1 |title=RFC 9112: HTTP/1.1}}</ref>
+क्लाइंट सर्वर को अनुरोध संदेश भेजता है, जिसमें निम्न सम्मिलित  हैं:<ref name="rfc9112-2.1">{{cite IETF |rfc=9112 |sectionname=Message format |section=2.1 |title=RFC 9112: HTTP/1.1}}</ref>
-* एक अनुरोध पंक्ति, जिसमें केस-संवेदी अनुरोध विधि, एक स्थान (विराम चिह्न), अनुरोधित URL, अन्य स्थान, प्रोटोकॉल संस्करण, एक [[कैरिज रिटर्न]] और एक [[रेखा भरण]] शामिल है, उदाहरण के लिए:
+* एक अनुरोध पंक्ति, जिसमें केस-संवेदी अनुरोध विधि, एक स्थान (विराम चिह्न), अनुरोधित URL, अन्य स्थान, प्रोटोकॉल संस्करण, एक [[कैरिज रिटर्न]] और एक [[रेखा भरण]] सम्मिलित  है, उदाहरण के लिए:
   प्राप्त करें /छवियां/logo.png एचटीटीपी/1.1
 * शून्य या अधिक HTTP अनुरोध शीर्षलेख फ़ील्ड (HTTP/1.1 के मामले में कम से कम 1 या अधिक शीर्षलेख), प्रत्येक में केस-असंवेदनशील फ़ील्ड नाम, एक कोलन, वैकल्पिक अग्रणी व्हाइटस्पेस (कंप्यूटर विज्ञान), फ़ील्ड मान, एक वैकल्पिक ट्रेलिंग व्हॉट्सएप और एक कैरिज रिटर्न और एक लाइन फीड के साथ समाप्त होता है, उदा .:
   होस्ट: www.example.com
   स्वीकार-भाषा: en
-* एक खाली लाइन, जिसमें कैरिज रिटर्न और लाइन फीड शामिल है;
+* एक खाली लाइन, जिसमें कैरिज रिटर्न और लाइन फीड सम्मिलित  है;
 * एक वैकल्पिक HTTP संदेश निकाय।
@@ Line 217: / Line 217: @@
 === अनुरोध के तरीके ===
-[[File:Http request telnet ubuntu.png|thumb|right|टेलनेट का उपयोग करके किया गया HTTP/1.1 अनुरोध। HTTP रिक्वेस्ट मैसेज, HTTP रिस्पांस हेडर सेक्शन और रिस्पॉन्स बॉडी हाइलाइट की गई हैं।]]HTTP तरीकों को परिभाषित करता है (कभी-कभी क्रियाओं के रूप में संदर्भित किया जाता है, लेकिन कहीं भी विनिर्देशन में यह क्रिया का उल्लेख नहीं करता है) पहचाने गए संसाधन पर वांछित क्रिया को इंगित करने के लिए। यह संसाधन क्या दर्शाता है, चाहे पूर्व-मौजूदा डेटा या डेटा जो गतिशील रूप से उत्पन्न होता है, सर्वर के कार्यान्वयन पर निर्भर करता है। अक्सर, संसाधन फ़ाइल या सर्वर पर निष्पादन योग्य के आउटपुट से मेल खाता है। HTTP/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> GET, HEAD और POST विधियों और HTTP / 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|टेलनेट का उपयोग करके किया गया HTTP/1.1 अनुरोध। HTTP रिक्वेस्ट मैसेज, HTTP रिस्पांस हेडर सेक्शन और रिस्पॉन्स बॉडी हाइलाइट की गई हैं।]]HTTP तरीकों को परिभाषित करता है (कभी-कभी क्रियाओं के रूप में संदर्भित किया जाता है, लेकिन कहीं भी विनिर्देशन में यह क्रिया का उल्लेख नहीं करता है) पहचाने गए संसाधन पर वांछित क्रिया को इंगित करने के लिए। यह संसाधन क्या दर्शाता है, चाहे पूर्व-मौजूदा डेटा या डेटा जो गतिशील रूप से उत्पन्न होता है, सर्वर के कार्यान्वयन पर निर्भर करता है। प्रायः, संसाधन फ़ाइल या सर्वर पर निष्पादन योग्य के आउटपुट से मेल खाता है। HTTP/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> GET, HEAD और POST विधियों और HTTP / 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> यह HTTP शीर्षलेख फ़ील्ड नामों के विपरीत है जो केस-असंवेदनशील हैं।<ref name="rfc9110-6.3">{{cite IETF |rfc=9110 |section=6.3 |sectionname=Header Fields |title=RFC 9110, HTTP Semantics}}</ref>
@@ Line 224: / Line 224: @@
 ; प्राप्त करें: GET विधि अनुरोध करती है कि लक्ष्य संसाधन अपने राज्य का प्रतिनिधित्व स्थानांतरित करे। GET अनुरोधों को केवल डेटा पुनर्प्राप्ति होना चाहिए और इसका कोई अन्य प्रभाव नहीं होना चाहिए। (यह कुछ अन्य एचटीटीपी विधियों के लिए भी सही है।)<ref name="rfc9110" />परिवर्तन किए बिना संसाधनों को पुनः प्राप्त करने के लिए, POST पर GET को प्राथमिकता दी जाती है, क्योंकि वे एक URL के माध्यम से [[ पता योग्यता ]] हो सकते हैं। यह बुकमार्क करने और साझा करने में सक्षम बनाता है और [[ब्राउज़र कैश]] के लिए प्रतिक्रिया प्राप्त करता है, जो बैंडविड्थ को बचा सकता है। [[W3C]] ने इस भेद पर मार्गदर्शन सिद्धांतों को प्रकाशित किया है, जिसमें कहा गया है, वेब एप्लिकेशन डिज़ाइन को उपरोक्त सिद्धांतों द्वारा सूचित किया जाना चाहिए, लेकिन प्रासंगिक सीमाओं द्वारा भी।<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> नीचे #सुरक्षित तरीके देखें।
-; HEAD: HEAD विधि अनुरोध करती है कि लक्ष्य संसाधन अपने राज्य का एक प्रतिनिधित्व स्थानांतरित करता है, जैसा कि GET अनुरोध के लिए होता है, लेकिन प्रतिक्रिया निकाय में संलग्न प्रतिनिधित्व डेटा के बिना। यह प्रतिक्रिया शीर्षलेख में प्रतिनिधित्व मेटाडेटा को पुनर्प्राप्त करने के लिए उपयोगी है, पूरे प्रतिनिधित्व को स्थानांतरित किए बिना। इसके उपयोगों में यह जांचना शामिल है कि [[HTTP स्थिति कोड]] के माध्यम से कोई पृष्ठ उपलब्ध है या नहीं और [[कम्प्यूटर फाइल]] के आकार का शीघ्रता से पता लगाना (<code>Content-Length</code>).
+; HEAD: HEAD विधि अनुरोध करती है कि लक्ष्य संसाधन अपने राज्य का एक प्रतिनिधित्व स्थानांतरित करता है, जैसा कि GET अनुरोध के लिए होता है, लेकिन प्रतिक्रिया निकाय में संलग्न प्रतिनिधित्व डेटा के बिना। यह प्रतिक्रिया शीर्षलेख में प्रतिनिधित्व मेटाडेटा को पुनर्प्राप्त करने के लिए उपयोगी है, पूरे प्रतिनिधित्व को स्थानांतरित किए बिना। इसके उपयोगों में यह जांचना सम्मिलित  है कि [[HTTP स्थिति कोड]] के माध्यम से कोई पृष्ठ उपलब्ध है या नहीं और [[कम्प्यूटर फाइल]] के आकार का शीघ्रता से पता लगाना (<code>Content-Length</code>).
 ; POST: [[POST (HTTP)]] अनुरोध करता है कि लक्ष्य संसाधन लक्ष्य संसाधन के शब्दार्थ के अनुसार अनुरोध में संलग्न प्रतिनिधित्व को संसाधित करता है। उदाहरण के लिए, इसका उपयोग [[इंटरनेट मंच]] पर संदेश पोस्ट करने, [[मेलिंग सूची]] की सदस्यता लेने या [[ऑनलाइन खरीदारी]] लेनदेन को पूरा करने के लिए किया जाता है।<ref name="rfc9110-9.3.3">{{cite IETF |rfc=9110 |sectionname=POST |section=9.3.3 |title=RFC 9110, HTTP Semantics}}</ref>
@@ Line 232: / Line 232: @@
 ; DELETE: DELETE विधि अनुरोध करती है कि लक्ष्य संसाधन अपनी स्थिति को हटा दें।
-; कनेक्ट: कनेक्ट विधि अनुरोध करती है कि मध्यस्थ अनुरोध लक्ष्य द्वारा पहचाने गए मूल सर्वर के लिए एक टनलिंग प्रोटोकॉल | टीसीपी / आईपी सुरंग स्थापित करता है। इसका उपयोग अक्सर ट्रांसपोर्ट लेयर सिक्योरिटी के साथ एक या एक से अधिक HTTP प्रॉक्सी के माध्यम से कनेक्शन सुरक्षित करने के लिए किया जाता है।<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> HTTP टनल#HTTP कनेक्ट विधि देखें।
+; कनेक्ट: कनेक्ट विधि अनुरोध करती है कि मध्यस्थ अनुरोध लक्ष्य द्वारा पहचाने गए मूल सर्वर के लिए एक टनलिंग प्रोटोकॉल | टीसीपी / आईपी सुरंग स्थापित करता है। इसका उपयोग प्रायः ट्रांसपोर्ट लेयर सिक्योरिटी के साथ एक या एक से अधिक HTTP प्रॉक्सी के माध्यम से कनेक्शन सुरक्षित करने के लिए किया जाता है।<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> HTTP टनल#HTTP कनेक्ट विधि देखें।
-; विकल्प: विकल्प विधि अनुरोध करती है कि लक्ष्य संसाधन HTTP विधियों को स्थानांतरित करता है जो इसका समर्थन करता है। इसका उपयोग किसी विशिष्ट संसाधन के बजाय '*' अनुरोध करके वेब सर्वर की कार्यक्षमता की जांच करने के लिए किया जा सकता है।
+; विकल्प: विकल्प विधि अनुरोध करती है कि लक्ष्य संसाधन HTTP विधियों को स्थानांतरित करता है जो इसका समर्थन करता है। इसका उपयोग किसी विशिष्ट संसाधन के अतिरिक्त '*' अनुरोध करके वेब सर्वर की कार्यक्षमता की जांच करने के लिए किया जा सकता है।
 ; TRACE: TRACE विधि अनुरोध करती है कि लक्ष्य संसाधन प्रतिक्रिया निकाय में प्राप्त अनुरोध को स्थानांतरित कर दे। इस तरह एक ग्राहक देख सकता है कि बिचौलियों द्वारा क्या (यदि कोई हो) परिवर्तन या परिवर्धन किया गया है।
@@ Line 329: / Line 329: @@
 एक अनुरोध विधि सुरक्षित है यदि उस विधि के अनुरोध का सर्वर पर कोई प्रभाव नहीं पड़ता है। GET, HEAD, OPTIONS और TRACE विधियों को सुरक्षित के रूप में परिभाषित किया गया है। दूसरे शब्दों में, कमांड-क्वेरी पृथक्करण|केवल-पढ़ने के लिए सुरक्षित विधियों का इरादा है। हालांकि वे [[साइड इफेक्ट (कंप्यूटर विज्ञान)]] को बाहर नहीं करते हैं, जैसे कि [[सर्वर लॉग]] में अनुरोध जानकारी को जोड़ना या वेब बैनर को चार्ज करना, क्योंकि परिभाषा के अनुसार क्लाइंट द्वारा उनका अनुरोध नहीं किया जाता है।
-इसके विपरीत, POST, PUT, DELETE, CONNECT, और PATCH के तरीके सुरक्षित नहीं हैं। वे सर्वर की स्थिति को संशोधित कर सकते हैं या [[ईमेल]] भेजने जैसे अन्य प्रभाव डाल सकते हैं। इस तरह के तरीके आमतौर पर [[इंटरनेट बॉट]] या वेब क्रॉलर के अनुरूप नहीं होते हैं; कुछ जो अनुरूप नहीं हैं, वे संदर्भ या परिणामों की परवाह किए बिना अनुरोध करते हैं।
+इसके विपरीत, POST, PUT, DELETE, CONNECT, और PATCH के तरीके सुरक्षित नहीं हैं। वे सर्वर की स्थिति को संशोधित कर सकते हैं या [[ईमेल]] भेजने जैसे अन्य प्रभाव डाल सकते हैं। इस तरह के तरीके सामान्यतः [[इंटरनेट बॉट]] या वेब क्रॉलर के अनुरूप नहीं होते हैं; कुछ जो अनुरूप नहीं हैं, वे संदर्भ या परिणामों की परवाह किए बिना अनुरोध करते हैं।
 जीईटी अनुरोधों की निर्धारित सुरक्षा के बावजूद, व्यवहार में सर्वर द्वारा उनकी हैंडलिंग किसी भी तरह से तकनीकी रूप से सीमित नहीं है। लापरवाह या जानबूझकर अनियमित प्रोग्रामिंग जीईटी अनुरोधों को सर्वर पर गैर-तुच्छ परिवर्तन करने की अनुमति दे सकती है। वेब कैशिंग, [[खोज इंजन]] और अन्य स्वचालित एजेंटों द्वारा सर्वर पर अनपेक्षित परिवर्तन करने पर उत्पन्न होने वाली समस्याओं के कारण इसे हतोत्साहित किया जाता है। उदाहरण के लिए, एक वेबसाइट <nowiki>https://example.com/article/1234/delete</nowiki> जैसे किसी URL के माध्यम से किसी संसाधन को हटाने की अनुमति दे सकती है, जो, यदि मनमाने ढंग से प्राप्त किया जाता है, यहां तक कि GET का उपयोग करके, बस हटा दिया जाएगा लेख।<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> एक ठीक से कोडित वेबसाइट को इस क्रिया के लिए DELETE या POST विधि की आवश्यकता होगी, जो गैर-दुर्भावनापूर्ण बॉट्स नहीं करेंगे।
@@ Line 339: / Line 339: @@
 एक अनुरोध विधि उदासीन है यदि उस विधि के साथ कई समान अनुरोधों का एक ही अनुरोध के समान प्रभाव होता है। PUT और DELETE के तरीके, और सुरक्षित तरीकों को idempotent के रूप में परिभाषित किया गया है। सुरक्षित तरीके तुच्छ रूप से बेकार हैं, क्योंकि उनका इरादा सर्वर पर किसी भी तरह का प्रभाव नहीं डालना है; इस बीच, PUT और DELETE विधियाँ उदासीन हैं क्योंकि क्रमिक समान अनुरोधों को अनदेखा कर दिया जाएगा। उदाहरण के लिए, एक वेबसाइट उपयोगकर्ता के रिकॉर्ड किए गए ईमेल पते को संशोधित करने के लिए एक PUT समापन बिंदु सेट कर सकती है। यदि यह समापन बिंदु सही ढंग से कॉन्फ़िगर किया गया है, तो कोई भी अनुरोध जो उपयोगकर्ता के ईमेल पते को उसी ईमेल पते में बदलने के लिए कहता है जो पहले से ही रिकॉर्ड किया गया है—उदा. एक सफल अनुरोध के बाद डुप्लिकेट अनुरोध—कोई प्रभाव नहीं पड़ेगा। इसी प्रकार, किसी निश्चित उपयोगकर्ता को हटाने के अनुरोध का कोई प्रभाव नहीं पड़ेगा यदि वह उपयोगकर्ता पहले ही हटा दिया गया हो।
-इसके विपरीत, विधियाँ POST, CONNECT, और PATCH आवश्यक रूप से निष्क्रिय नहीं हैं, और इसलिए एक समान POST अनुरोध को कई बार भेजने से सर्वर की स्थिति में और बदलाव हो सकता है या आगे के प्रभाव हो सकते हैं, जैसे कि कई ईमेल भेजना। कुछ मामलों में यह वांछित प्रभाव है, लेकिन अन्य मामलों में यह आकस्मिक रूप से हो सकता है। एक उपयोगकर्ता, उदाहरण के लिए, अनजाने में एक बटन को फिर से क्लिक करके कई POST अनुरोध भेज सकता है यदि उन्हें स्पष्ट प्रतिक्रिया नहीं दी गई थी कि पहला क्लिक संसाधित किया जा रहा था। जबकि वेब ब्राउज़र कुछ मामलों में उपयोगकर्ताओं को चेतावनी देने के लिए [[अलर्ट डायलॉग बॉक्स]] दिखा सकते हैं, जहां पृष्ठ को फिर से लोड करने से POST अनुरोध फिर से सबमिट हो सकता है, यह आम तौर पर उन मामलों को संभालने के लिए वेब एप्लिकेशन पर निर्भर करता है जहां POST अनुरोध एक से अधिक बार सबमिट नहीं किया जाना चाहिए।
+इसके विपरीत, विधियाँ POST, CONNECT, और PATCH आवश्यक रूप से निष्क्रिय नहीं हैं, और इसलिए एक समान POST अनुरोध को कई बार भेजने से सर्वर की स्थिति में और बदलाव हो सकता है या आगे के प्रभाव हो सकते हैं, जैसे कि कई ईमेल भेजना। कुछ मामलों में यह वांछित प्रभाव है, लेकिन अन्य मामलों में यह आकस्मिक रूप से हो सकता है। एक उपयोगकर्ता, उदाहरण के लिए, अनजाने में एक बटन को फिर से क्लिक करके कई POST अनुरोध भेज सकता है यदि उन्हें स्पष्ट प्रतिक्रिया नहीं दी गई थी कि पहला क्लिक संसाधित किया जा रहा था। जबकि वेब ब्राउज़र कुछ मामलों में उपयोगकर्ताओं को चेतावनी देने के लिए [[अलर्ट डायलॉग बॉक्स]] दिखा सकते हैं, जहां पृष्ठ को फिर से लोड करने से POST अनुरोध फिर से सबमिट हो सकता है, यह सामान्यतः उन मामलों को संभालने के लिए वेब एप्लिकेशन पर निर्भर करता है जहां POST अनुरोध एक से अधिक बार सबमिट नहीं किया जाना चाहिए।
 ध्यान दें कि कोई विधि निष्क्रिय है या नहीं, प्रोटोकॉल या वेब सर्वर द्वारा लागू नहीं किया जाता है। एक वेब एप्लिकेशन लिखना पूरी तरह से संभव है जिसमें (उदाहरण के लिए) एक डेटाबेस इन्सर्ट या अन्य नॉन-इम्पोटेंट एक्शन को GET या अन्य अनुरोध द्वारा ट्रिगर किया जाता है। सिफारिशों के विरुद्ध ऐसा करने के लिए, हालांकि, अवांछित परिणाम हो सकते हैं, यदि कोई उपयोगकर्ता एजेंट मानता है कि एक ही अनुरोध को दोहराना सुरक्षित है, जबकि ऐसा नहीं है।
@@ Line 357: / Line 357: @@
 === प्रतिक्रिया सिंटैक्स ===
-एक सर्वर क्लाइंट को प्रतिक्रिया संदेश भेजता है, जिसमें शामिल हैं:<ref name="rfc9112-2.1" />
+एक सर्वर क्लाइंट को प्रतिक्रिया संदेश भेजता है, जिसमें सम्मिलित  हैं:<ref name="rfc9112-2.1" />
-* एक स्टेटस लाइन, जिसमें प्रोटोकॉल संस्करण, एक स्पेस (विराम चिह्न), HTTP स्टेटस कोड की सूची, एक अन्य स्पेस, एक संभावित खाली कारण वाक्यांश, एक कैरिज रिटर्न और एक लाइन फीड शामिल है, उदाहरण के लिए:
+* एक स्टेटस लाइन, जिसमें प्रोटोकॉल संस्करण, एक स्पेस (विराम चिह्न), HTTP स्टेटस कोड की सूची, एक अन्य स्पेस, एक संभावित खाली कारण वाक्यांश, एक कैरिज रिटर्न और एक लाइन फीड सम्मिलित  है, उदाहरण के लिए:
   HTTP/1.1 200 ठीक है
 * शून्य या अधिक HTTP प्रतिक्रिया शीर्षलेख फ़ील्ड, प्रत्येक में केस-असंवेदनशील फ़ील्ड नाम, एक कोलन, वैकल्पिक अग्रणी व्हाइटस्पेस (कंप्यूटर विज्ञान), फ़ील्ड मान, एक वैकल्पिक अनुगामी व्हाइटस्पेस और एक कैरिज रिटर्न और एक लाइन फीड के साथ समाप्त होता है, उदाहरण के लिए :
   सामग्री-प्रकार: पाठ/एचटीएमएल
-* एक खाली लाइन, जिसमें कैरिज रिटर्न और लाइन फीड शामिल है;
+* एक खाली लाइन, जिसमें कैरिज रिटर्न और लाइन फीड सम्मिलित  है;
 * एक वैकल्पिक HTTP संदेश निकाय।
 === प्रतिक्रिया स्थिति कोड ===
 {{See also|List of HTTP status codes}}
-HTTP/1.0 में और उसके बाद से, HTTP प्रतिक्रिया की पहली पंक्ति को स्थिति रेखा कहा जाता है और इसमें एक संख्यात्मक स्थिति कोड (जैसे [[HTTP 404]]) और एक शाब्दिक कारण वाक्यांश (जैसे नहीं मिला) शामिल होता है। प्रतिक्रिया स्थिति कोड एक तीन अंकों का पूर्णांक कोड है जो क्लाइंट के संबंधित अनुरोध को समझने और संतुष्ट करने के सर्वर के प्रयास के परिणाम का प्रतिनिधित्व करता है। जिस तरह से ग्राहक प्रतिक्रिया को संभालता है वह मुख्य रूप से स्थिति कोड पर निर्भर करता है, और दूसरा प्रतिक्रिया हेडर फ़ील्ड पर। ग्राहक सभी पंजीकृत स्थिति कोड को नहीं समझ सकते हैं, लेकिन उन्हें अपनी कक्षा (स्थिति कोड के पहले अंक द्वारा दी गई) को समझना चाहिए और उस वर्ग के x00 स्थिति कोड के बराबर होने के लिए एक गैर-मान्यता प्राप्त स्थिति कोड का इलाज करना चाहिए।
+HTTP/1.0 में और उसके बाद से, HTTP प्रतिक्रिया की पहली पंक्ति को स्थिति रेखा कहा जाता है और इसमें एक संख्यात्मक स्थिति कोड (जैसे [[HTTP 404]]) और एक शाब्दिक कारण वाक्यांश (जैसे नहीं मिला) सम्मिलित  होता है। प्रतिक्रिया स्थिति कोड एक तीन अंकों का पूर्णांक कोड है जो क्लाइंट के संबंधित अनुरोध को समझने और संतुष्ट करने के सर्वर के प्रयास के परिणाम का प्रतिनिधित्व करता है। जिस तरह से ग्राहक प्रतिक्रिया को संभालता है वह मुख्य रूप से स्थिति कोड पर निर्भर करता है, और दूसरा प्रतिक्रिया हेडर फ़ील्ड पर। ग्राहक सभी पंजीकृत स्थिति कोड को नहीं समझ सकते हैं, लेकिन उन्हें अपनी कक्षा (स्थिति कोड के पहले अंक द्वारा दी गई) को समझना चाहिए और उस वर्ग के x00 स्थिति कोड के बराबर होने के लिए एक गैर-मान्यता प्राप्त स्थिति कोड का इलाज करना चाहिए।
 मानक कारण वाक्यांश केवल अनुशंसाएँ हैं, और वेब डेवलपर के विवेक पर स्थानीय समकक्षों के साथ बदले जा सकते हैं। यदि स्थिति कोड किसी समस्या का संकेत देता है, तो उपयोगकर्ता एजेंट समस्या की प्रकृति के बारे में अधिक जानकारी प्रदान करने के लिए उपयोगकर्ता को कारण वाक्यांश प्रदर्शित कर सकता है। मानक भी उपयोगकर्ता एजेंट को कारण वाक्यांश की व्याख्या करने का प्रयास करने की अनुमति देता है, हालांकि यह नासमझी हो सकती है क्योंकि मानक स्पष्ट रूप से निर्दिष्ट करता है कि स्थिति कोड मशीन-पठनीय हैं और कारण वाक्यांश मानव-पठनीय हैं।
@@ Line 404: / Line 404: @@
 </syntaxhighlight>
-एक ग्राहक अनुरोध (अनुरोध पंक्ति के इस मामले में और कुछ शीर्षलेख शामिल हैं जिन्हें केवल <code>"Host: hostname"</code> हेडर) के बाद एक खाली लाइन होती है, ताकि अनुरोध लाइन के दोहरे सिरे के साथ समाप्त हो, प्रत्येक कैरिज रिटर्न के रूप में और उसके बाद लाइन फीड हो। <code>"Host: hostname"</code> e> शीर्ष लेख मान विभिन्न [[डोमेन की नामांकन प्रणाली]] नामों के बीच एक एकल आईपी पता साझा करने के बीच अंतर करता है, जिससे नाम-आधारित वर्चुअल होस्टिंग की अनुमति मिलती है। जबकि HTTP/1.0 में वैकल्पिक है, HTTP/1.1 में यह अनिवार्य है। (ए / (स्लैश) आमतौर पर एक वेबसर्वर डायरेक्टरी इंडेक्स|/index.html फ़ाइल लाएगा यदि कोई है।)
+एक ग्राहक अनुरोध (अनुरोध पंक्ति के इस मामले में और कुछ शीर्षलेख सम्मिलित  हैं जिन्हें केवल <code>"Host: hostname"</code> हेडर) के बाद एक खाली लाइन होती है, ताकि अनुरोध लाइन के दोहरे सिरे के साथ समाप्त हो, प्रत्येक कैरिज रिटर्न के रूप में और उसके बाद लाइन फीड हो। <code>"Host: hostname"</code> e> शीर्ष लेख मान विभिन्न [[डोमेन की नामांकन प्रणाली]] नामों के बीच एक एकल आईपी पता साझा करने के बीच अंतर करता है, जिससे नाम-आधारित वर्चुअल होस्टिंग की अनुमति मिलती है। जबकि HTTP/1.0 में वैकल्पिक है, HTTP/1.1 में यह अनिवार्य है। (ए / (स्लैश) सामान्यतः एक वेबसर्वर डायरेक्टरी इंडेक्स|/index.html फ़ाइल लाएगा यदि कोई है।)
 === सर्वर प्रतिक्रिया ===

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


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

Anonymous

Search