HTTP रेफरर: Difference between revisions
(Created page with "{{Short description|HTTP header field}} {{HTTP}} हाइपरटेक्स्ट परहस्त शिष्टाचार में,{{Not a typo|Referer}} (...") |
No edit summary |
||
Line 6: | Line 6: | ||
[[वेबसाइट]] और [[वेब सर्वर]] सर्वर प्राप्त की सामग्री को लॉग करते हैं {{Not a typo|Referer}} फ़ील्ड उस वेब पेज की पहचान करने के लिए जिससे उपयोगकर्ता प्रचार या सांख्यिकीय उद्देश्यों के लिए एक लिंक का अनुसरण करता है।<ref name="gjEm8" />इससे उपयोगकर्ता के लिए [[सूचना गोपनीयता]] का नुकसान होता है और [[सुरक्षा]] जोखिम पेश हो सकता है।<ref name="Leak" />सुरक्षा जोखिमों को कम करने के लिए, रेफ़रर में भेजी गई जानकारी की मात्रा को ब्राउज़र लगातार कम कर रहे हैं। मार्च 2021 तक, डिफ़ॉल्ट रूप से [[Google Chrome]],<ref name="N9xNj" />[[क्रोमियम (वेब ब्राउज़र)]] आधारित [[ माइक्रोसॉफ्ट बढ़त ]], [[ फ़ायरफ़ॉक्स ]],<ref name="6l6dr" />[[सफारी (वेब ब्राउज़र)]]<ref>{{Cite web|url=https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/|title=ट्रैकिंग की रोकथाम ट्रैकिंग की रोकथाम|first=John|last=Wilander|website=WebKit blog|date=December 10, 2019|df=ymd}}</ref> क्रॉस-ऑरिजिन अनुरोधों में केवल मूल भेजने के लिए डिफ़ॉल्ट, डोमेन नाम के अलावा सब कुछ अलग करना। | [[वेबसाइट]] और [[वेब सर्वर]] सर्वर प्राप्त की सामग्री को लॉग करते हैं {{Not a typo|Referer}} फ़ील्ड उस वेब पेज की पहचान करने के लिए जिससे उपयोगकर्ता प्रचार या सांख्यिकीय उद्देश्यों के लिए एक लिंक का अनुसरण करता है।<ref name="gjEm8" />इससे उपयोगकर्ता के लिए [[सूचना गोपनीयता]] का नुकसान होता है और [[सुरक्षा]] जोखिम पेश हो सकता है।<ref name="Leak" />सुरक्षा जोखिमों को कम करने के लिए, रेफ़रर में भेजी गई जानकारी की मात्रा को ब्राउज़र लगातार कम कर रहे हैं। मार्च 2021 तक, डिफ़ॉल्ट रूप से [[Google Chrome]],<ref name="N9xNj" />[[क्रोमियम (वेब ब्राउज़र)]] आधारित [[ माइक्रोसॉफ्ट बढ़त ]], [[ फ़ायरफ़ॉक्स ]],<ref name="6l6dr" />[[सफारी (वेब ब्राउज़र)]]<ref>{{Cite web|url=https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/|title=ट्रैकिंग की रोकथाम ट्रैकिंग की रोकथाम|first=John|last=Wilander|website=WebKit blog|date=December 10, 2019|df=ymd}}</ref> क्रॉस-ऑरिजिन अनुरोधों में केवल मूल भेजने के लिए डिफ़ॉल्ट, डोमेन नाम के अलावा सब कुछ अलग करना। | ||
'''[[सामग्री सुरक्षा नीति]] मानक संस्करण 1.1 ने एक नया रेफरर निर्देश पेश किया जो रेफरर हेडर के संबंध में ब्राउज़र के व्यवहार पर अधिक नियंत्रण की अनुमति देता है। विशेष रूप से यह वेबमास्टर को ब्राउज़र को निर्देश देने की अनुमति देता है कि वह रेफरर को बिल्कुल भी ब्लॉक न करे, केवल उसी मूल के साथ चलते समय इसे प्रकट करे आदि।<ref name="kmzCq" />''' | |||
== व्युत्पत्ति == | == व्युत्पत्ति == | ||
Line 23: | Line 25: | ||
== | == रेफरर छुपा == | ||
अधिकांश वेब सर्वर सभी ट्रैफ़िक के लॉग बनाए रखते हैं, और प्रत्येक अनुरोध के लिए वेब ब्राउज़र द्वारा भेजे गए HTTP रेफरर को रिकॉर्ड करते हैं। यह कई गोपनीयता संबंधी चिंताओं को जन्म देता है, और परिणामस्वरूप, वेब सर्वरों को वास्तविक रेफ़रिंग URL भेजे जाने से रोकने के लिए कई प्रणालियाँ विकसित की गई हैं। ये सिस्टम या तो रेफ़रलकर्ता फ़ील्ड को खाली करके या इसे गलत डेटा से बदलकर काम करते हैं। आम तौर पर, [[इंटरनेट सुरक्षा]]|इंटरनेट-सुरक्षा सूट रेफरर डेटा को खाली कर देते हैं, जबकि वेब-आधारित सर्वर इसे एक झूठे URL से बदल देते हैं, आमतौर पर उनका अपना। इससे रेफरर स्पैम की समस्या बढ़ जाती है। दोनों विधियों के तकनीकी विवरण काफी सुसंगत हैं - सॉफ़्टवेयर अनुप्रयोग प्रॉक्सी सर्वर के रूप में कार्य करते हैं और HTTP अनुरोध में हेरफेर करते हैं, जबकि वेब-आधारित विधियाँ फ़्रेम के भीतर वेबसाइटों को लोड करती हैं, जिसके कारण वेब ब्राउज़र उनके वेबसाइट पते का एक रेफ़रलकर्ता URL भेजता है। कुछ वेब ब्राउज़र अपने उपयोगकर्ताओं को अनुरोध हेडर में रेफ़रलकर्ता फ़ील्ड को बंद करने का विकल्प देते हैं।<ref name="sendRefererHeader" /> | अधिकांश वेब सर्वर सभी ट्रैफ़िक के लॉग बनाए रखते हैं, और प्रत्येक अनुरोध के लिए वेब ब्राउज़र द्वारा भेजे गए HTTP रेफरर को रिकॉर्ड करते हैं। यह कई गोपनीयता संबंधी चिंताओं को जन्म देता है, और परिणामस्वरूप, वेब सर्वरों को वास्तविक रेफ़रिंग URL भेजे जाने से रोकने के लिए कई प्रणालियाँ विकसित की गई हैं। ये सिस्टम या तो रेफ़रलकर्ता फ़ील्ड को खाली करके या इसे गलत डेटा से बदलकर काम करते हैं। आम तौर पर, [[इंटरनेट सुरक्षा]]|इंटरनेट-सुरक्षा सूट रेफरर डेटा को खाली कर देते हैं, जबकि वेब-आधारित सर्वर इसे एक झूठे URL से बदल देते हैं, आमतौर पर उनका अपना। इससे रेफरर स्पैम की समस्या बढ़ जाती है। दोनों विधियों के तकनीकी विवरण काफी सुसंगत हैं - सॉफ़्टवेयर अनुप्रयोग प्रॉक्सी सर्वर के रूप में कार्य करते हैं और HTTP अनुरोध में हेरफेर करते हैं, जबकि वेब-आधारित विधियाँ फ़्रेम के भीतर वेबसाइटों को लोड करती हैं, जिसके कारण वेब ब्राउज़र उनके वेबसाइट पते का एक रेफ़रलकर्ता URL भेजता है। कुछ वेब ब्राउज़र अपने उपयोगकर्ताओं को अनुरोध हेडर में रेफ़रलकर्ता फ़ील्ड को बंद करने का विकल्प देते हैं।<ref name="sendRefererHeader" /> | ||
Revision as of 11:08, 13 May 2023
HTTP |
---|
Request methods |
Header fields |
Response status codes |
Security access control methods |
Security vulnerabilities |
हाइपरटेक्स्ट परहस्त शिष्टाचार में,Referer (रेफरर की गलत वर्तनी[1] HTTP हेडर फ़ील्ड की एक वैकल्पिक सूची है जो वेब पृष्ठ (यानी, यूनिफॉर्म रिसोर्स पहचानकर्ता या अंतर्राष्ट्रीय संसाधन पहचानकर्ता) के पते की पहचान करती है, जिससे संसाधन का अनुरोध किया गया है। रेफ़रलकर्ता की जाँच करके, नया वेब पेज प्रदान करने वाला सर्वर यह देख सकता है कि अनुरोध कहाँ उत्पन्न हुआ है।
सबसे आम स्थिति में, इसका मतलब यह है कि जब कोई उपयोगकर्ता वेब ब्राउज़र में हाइपरलिंक पर क्लिक करता है, जिससे ब्राउज़र गंतव्य वेब पेज वाले सर्वर को अनुरोध भेजता है, तो अनुरोध में शामिल हो सकता है Referer फ़ील्ड, जो उस अंतिम पृष्ठ को इंगित करता है जिस पर उपयोगकर्ता था (वह स्थान जहाँ उन्होंने लिंक पर क्लिक किया था)।
वेबसाइट और वेब सर्वर सर्वर प्राप्त की सामग्री को लॉग करते हैं Referer फ़ील्ड उस वेब पेज की पहचान करने के लिए जिससे उपयोगकर्ता प्रचार या सांख्यिकीय उद्देश्यों के लिए एक लिंक का अनुसरण करता है।[2]इससे उपयोगकर्ता के लिए सूचना गोपनीयता का नुकसान होता है और सुरक्षा जोखिम पेश हो सकता है।[3]सुरक्षा जोखिमों को कम करने के लिए, रेफ़रर में भेजी गई जानकारी की मात्रा को ब्राउज़र लगातार कम कर रहे हैं। मार्च 2021 तक, डिफ़ॉल्ट रूप से Google Chrome,[4]क्रोमियम (वेब ब्राउज़र) आधारित माइक्रोसॉफ्ट बढ़त , फ़ायरफ़ॉक्स ,[5]सफारी (वेब ब्राउज़र)[6] क्रॉस-ऑरिजिन अनुरोधों में केवल मूल भेजने के लिए डिफ़ॉल्ट, डोमेन नाम के अलावा सब कुछ अलग करना।
सामग्री सुरक्षा नीति मानक संस्करण 1.1 ने एक नया रेफरर निर्देश पेश किया जो रेफरर हेडर के संबंध में ब्राउज़र के व्यवहार पर अधिक नियंत्रण की अनुमति देता है। विशेष रूप से यह वेबमास्टर को ब्राउज़र को निर्देश देने की अनुमति देता है कि वह रेफरर को बिल्कुल भी ब्लॉक न करे, केवल उसी मूल के साथ चलते समय इसे प्रकट करे आदि।[7]
व्युत्पत्ति
विक्ट की गलत वर्तनी: रेफरर को मूल प्रस्ताव में कंप्यूटर वैज्ञानिक फिलिप हॉलम-बेकर द्वारा शामिल करने के लिए पेश किया गया था "Referer" हैडर फ़ील्ड HTTP विनिर्देशन में।[8]टिप्पणियों के लिए अनुरोध स्टैंडर्ड्स डॉक्यूमेंट RFC 1945 में शामिल किए जाने के समय (मई 1996) तक गलत स्पेलिंग पत्थर की लकीर बन गई थी।[9](जो 'उस समय HTTP/1.0' के रूप में संदर्भित प्रोटोकॉल के सामान्य उपयोग को दर्शाता है); दस्तावेज़ के सह-लेखक रॉय फील्डिंग ने मार्च 1995 में टिप्पणी की कि कोई भी (referer या रेफरर) अवधि के मानक वर्तनी (यूनिक्स) द्वारा समझा जाता है।[10] "Referer" तब से HTTP रेफरर्स पर चर्चा करते समय उद्योग में व्यापक रूप से इस्तेमाल की जाने वाली वर्तनी बन गई है; गलत वर्तनी का उपयोग सार्वभौमिक नहीं है, हालांकि, कुछ वेब विशिष्टताओं जैसे में सही वर्तनी रेफ़रलकर्ता का उपयोग किया जाता है Referrer-Policy
HTTP हेडर या दस्तावेज़ ऑब्जेक्ट मॉडल।[3]
विवरण
किसी वेब पेज पर जाने पर, रेफ़रलकर्ता या रेफ़रिंग पेज पिछले वेब पेज का URL होता है जिससे एक लिंक का अनुसरण किया गया था।
आम तौर पर, एक रेफ़रलकर्ता पिछले आइटम का URL होता है जिसके कारण यह अनुरोध किया गया था। एक छवि के लिए रेफरर, उदाहरण के लिए, आम तौर पर HTML पृष्ठ होता है जिस पर इसे प्रदर्शित किया जाना है। रेफरर फ़ील्ड वेब ब्राउज़र द्वारा वेब सर्वर पर भेजे गए HTTP अनुरोध का एक वैकल्पिक हिस्सा है।[11]
कई वेबसाइटें वेब ट्रैकिंग के अपने प्रयास के भाग के रूप में संदर्भकर्ताओं को लॉग करती हैं। अधिकांश वेब लॉग विश्लेषण सॉफ़्टवेयर इस जानकारी को संसाधित कर सकते हैं। क्योंकि रेफ़रलकर्ता जानकारी गोपनीयता का उल्लंघन कर सकती है, कुछ वेब ब्राउज़र उपयोगकर्ता को रेफ़रलकर्ता जानकारी भेजने को अक्षम करने की अनुमति देते हैं।[12]गैर-सार्वजनिक वेबसाइटों के स्थान को लीक होने से बचाने के लिए कुछ प्रॉक्सी सर्वर और फ़ायरवॉल (नेटवर्किंग) सॉफ़्टवेयर भी रेफ़रलकर्ता जानकारी को फ़िल्टर कर देंगे। यह, बदले में, समस्याएँ पैदा कर सकता है: कुछ वेब सर्वर अपनी वेबसाइट के कुछ हिस्सों को उन वेब ब्राउज़रों के लिए ब्लॉक कर देते हैं जो डीप लिंकिंग या छवियों के अनधिकृत उपयोग (बैंडविड्थ चोरी) को रोकने के प्रयास में सही रेफ़रलकर्ता जानकारी नहीं भेजते हैं। कुछ प्रॉक्सी सॉफ़्टवेयर में लक्ष्य वेबसाइट के शीर्ष-स्तरीय पते को रेफ़रलकर्ता के रूप में देने की क्षमता होती है, जो इन समस्याओं को कम करता है लेकिन फिर भी कुछ मामलों में उपयोगकर्ता के अंतिम-देखे गए वेब पेज को प्रकट कर सकता है।
कई ब्लॉग उन लोगों से लिंक करने के लिए रेफरर जानकारी प्रकाशित करते हैं जो उन्हें लिंक कर रहे हैं, और इस प्रकार बातचीत को विस्तृत करते हैं। इसने रेफरर स्पैम के उदय के बदले में नेतृत्व किया है: स्पैमर की वेबसाइट को लोकप्रिय बनाने के लिए नकली रेफरर जानकारी भेजना।
जावास्क्रिप्ट में document.referrer का उपयोग कर क्लाइंट साइड पर रेफरर जानकारी तक पहुंचना संभव है।[13]इसका उपयोग, उदाहरण के लिए, उपयोगकर्ता की खोज इंजन क्वेरी के आधार पर एक वेब पेज को वैयक्तिकृत करने के लिए किया जा सकता है। हालांकि, रेफ़रलकर्ता फ़ील्ड में हमेशा खोज कीवर्ड शामिल नहीं होते हैं, जैसे https के साथ Google खोज का उपयोग करते समय।[14]
रेफरर छुपा
अधिकांश वेब सर्वर सभी ट्रैफ़िक के लॉग बनाए रखते हैं, और प्रत्येक अनुरोध के लिए वेब ब्राउज़र द्वारा भेजे गए HTTP रेफरर को रिकॉर्ड करते हैं। यह कई गोपनीयता संबंधी चिंताओं को जन्म देता है, और परिणामस्वरूप, वेब सर्वरों को वास्तविक रेफ़रिंग URL भेजे जाने से रोकने के लिए कई प्रणालियाँ विकसित की गई हैं। ये सिस्टम या तो रेफ़रलकर्ता फ़ील्ड को खाली करके या इसे गलत डेटा से बदलकर काम करते हैं। आम तौर पर, इंटरनेट सुरक्षा|इंटरनेट-सुरक्षा सूट रेफरर डेटा को खाली कर देते हैं, जबकि वेब-आधारित सर्वर इसे एक झूठे URL से बदल देते हैं, आमतौर पर उनका अपना। इससे रेफरर स्पैम की समस्या बढ़ जाती है। दोनों विधियों के तकनीकी विवरण काफी सुसंगत हैं - सॉफ़्टवेयर अनुप्रयोग प्रॉक्सी सर्वर के रूप में कार्य करते हैं और HTTP अनुरोध में हेरफेर करते हैं, जबकि वेब-आधारित विधियाँ फ़्रेम के भीतर वेबसाइटों को लोड करती हैं, जिसके कारण वेब ब्राउज़र उनके वेबसाइट पते का एक रेफ़रलकर्ता URL भेजता है। कुछ वेब ब्राउज़र अपने उपयोगकर्ताओं को अनुरोध हेडर में रेफ़रलकर्ता फ़ील्ड को बंद करने का विकल्प देते हैं।[12]
अधिकांश वेब ब्राउज़र रेफ़रलकर्ता फ़ील्ड नहीं भेजते हैं जब उन्हें ताज़ा फ़ील्ड का उपयोग करके रीडायरेक्ट करने का निर्देश दिया जाता है। इसमें ओपेरा (वेब ब्राउज़र) के कुछ संस्करण और कई मोबाइल वेब ब्राउज़र शामिल नहीं हैं। हालाँकि, पुनर्निर्देशन की इस पद्धति को विश्वव्यापी वेब संकाय (W3C) द्वारा हतोत्साहित किया जाता है।[15]
यदि किसी वेबसाइट को HTTP सिक्योर (HTTPS) कनेक्शन से एक्सेस किया जाता है और लिंक किसी अन्य सुरक्षित स्थान को छोड़कर कहीं भी इंगित करता है, तो रेफ़रलकर्ता फ़ील्ड नहीं भेजा जाता है।[16]
विशेषता/मान के लिए HTML5 मानक जोड़ा गया समर्थन rel="noreferrer"
, जो उपयोगकर्ता एजेंट को रेफ़रलकर्ता नहीं भेजने का निर्देश देता है।[17]
एक अन्य रेफरर छिपाने की विधि मूल लिंक यूआरएल को डेटा यूआरआई स्कीम-आधारित यूआरएल में परिवर्तित करना है जिसमें मूल यूआरएल के मेटा रिफ्रेश के साथ छोटे एचटीएमएल पेज शामिल हैं। जब उपयोगकर्ता को से पुनर्निर्देशित किया जाता है data:
पृष्ठ, मूल रेफ़रलकर्ता छिपा हुआ है।
सामग्री सुरक्षा नीति मानक संस्करण 1.1 ने एक नया रेफरर निर्देश पेश किया जो रेफरर हेडर के संबंध में ब्राउज़र के व्यवहार पर अधिक नियंत्रण की अनुमति देता है। विशेष रूप से यह वेबमास्टर को ब्राउज़र को निर्देश देने की अनुमति देता है कि वह रेफरर को बिल्कुल भी ब्लॉक न करे, केवल उसी मूल के साथ चलते समय इसे प्रकट करे आदि।[7]
संदर्भ
- ↑ Gourley, David; Totty, Brian; Sayer, Marjorie; Aggarwal, Anshu; Reddy, Sailu (27 September 2002). HTTP:The Definitive Guide. ISBN 9781565925090.
- ↑ Kyrnin, Jennifer (2012-04-10). "Referrer - What is a Referrer - How do HTTP Referrers Work?". About.com. Retrieved 2013-03-20.
- ↑ 3.0 3.1 "Does your website have a leak?". ICO Blog. 2015-09-16. Archived from the original on 2018-05-24. Retrieved 2018-08-16.
- ↑ "Referrer Policy: Default to strict-origin-when-cross-origin - Chrome Platform Status". www.chromestatus.com. Retrieved 2021-03-23.
- ↑ Lee, Dimi; Kerschbaumer, Christoph. "Firefox 87 trims HTTP Referrers by default to protect user privacy". Mozilla Security Blog (in English). Retrieved 2021-03-23.
- ↑ Wilander, John (2019-12-10). "ट्रैकिंग की रोकथाम ट्रैकिंग की रोकथाम". WebKit blog.
- ↑ 7.0 7.1 "Content Security Policy Level 2". W3. 2014. Retrieved 2014-12-08.
- ↑ Hallam-Baker, Phillip (2000-09-21). "Re: Is Al Gore The Father of the Internet?". alt.folklore.computers. Retrieved 2013-03-20.
- ↑ Berners-Lee, T.; Fielding, R.; Frystyk, H. (May 1996). Hypertext Transfer Protocol -- HTTP/1.0. IETF. doi:10.17487/RFC1945. RFC 1945.
- ↑ Fielding, Roy (1995-03-09). "Re: referer: (sic)". ietf-http-wg-old. Retrieved 2013-03-20.
- ↑ Fielding, R.; Reschke, J. (June 2014). Fielding, R.; Reschke, J. (eds.). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (RFC 7231 § 5.5.2)". IETF. doi:10.17487/RFC7231. S2CID 14399078. Retrieved 2014-07-26.
The "referrer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained […]
{{cite journal}}
: Cite journal requires|journal=
(help) - ↑ 12.0 12.1 "Network.http.sendRefererHeader". MozillaZine. 2007-06-10. Retrieved 2015-05-27.
- ↑ "HTML DOM Document referrer Property". w3schools.com. Retrieved 2013-03-20.
- ↑ Gundersen, Bret (2011-10-19). "The Impact of Google Encrypted Search". Adobe Digital Marketing Blog. Retrieved 2021-03-17.
- ↑ "HTML Techniques for Web Content Accessibility Guidelines 1.0: The META element". W3C. 2000-11-06. Retrieved 2013-03-20.
- ↑ Fielding, R.; Reschke, J. (June 2014). Fielding, R.; Reschke, J. (eds.). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content: referrer (RFC 7231 § 5.5.2)". IETF. doi:10.17487/RFC7231. S2CID 14399078. Retrieved 2014-07-26.
A user agent MUST NOT send a referrer header field in an unsecured HTTP request if the referring page was received with a secure protocol
{{cite journal}}
: Cite journal requires|journal=
(help) - ↑ "4.12 Links — HTML Living Standard: 4.12.5.8 Link type "noreferrer"". WHATWG. 2016-02-19. Retrieved 2016-02-19.
बाहरी संबंध
- RFC 1945: Hypertext Transfer Protocol -- HTTP/1.0
- RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- RFC 3987: Internationalized Resource Identifiers (IRIs)
- Referrer Policy - W3C Editor's Draft