HTTP Request Header - Referer Explained

Referer सर्वर को रिक्वेस्ट के स्रोत की जानकारी देता है (ट्रैकिंग/सुरक्षा के लिए)। क्या यह हैडर डोमेन परिवर्तन पर क्लाइंट द्वारा सर्वर को भेजा जाता है? यदि हां तो यदि दो-तीन डोमेन को ऐसे ही जंप किया जाए तो रेफरर में किस डोमेन का नाम आएगा पहले या इमीडिएट लास्ट का?

Referer हेडर क्या है?

  • परिभाषा: Refererहेडर HTTP रिक्वेस्ट में शामिल होता है और उस URL को दर्शाता है, जिस पेज से रिक्वेस्ट शुरू हुई थी। यह सर्वर को रिक्वेस्ट के स्रोत (source) की जानकारी देता है।
    • उद्देश्य:
  1. ट्रैकिंग: यह जानने के लिए कि यूजर कहां से आया (जैसे सर्च इंजन, सोशल मीडिया, या दूसरी साइट)।
  2. सुरक्षा: संदिग्ध रिक्वेस्ट (जैसे CSRF हमले) की जांच के लिए।
  3. विश्लेषण: वेबसाइट ट्रैफिक के स्रोत को समझने के लिए।
  • प्रारूप:

Referer: <URL>

  • उदाहरण:Referer: https://example.com/page1.html
  • नोट: यह हेडर वैकल्पिक है और कुछ शर्तों (जैसे गोपनीयता नीतियां) में शामिल नहीं हो सकता।

 

क्या Referer हेडर डोमेन परिवर्तन पर भेजा जाता है?

  • हां, आमतौर पर भेजा जाता है: जब क्लाइंट (ब्राउज़र) एक डोमेन से दूसरे डोमेन पर रिक्वेस्ट भेजता है (क्रॉस-डोमेन रिक्वेस्ट), तो ब्राउज़र स्वचालित रूप सेReferer हेडर जोड़ता है, जिसमें उस पेज का URL होता है, जहां से रिक्वेस्ट शुरू हुई। उदाहरण: अगर यूजर https://example.com पर है और वहां से एक लिंक पर क्लिक करके https://api.example.org पर जाता है, तो रिक्वेस्ट में यह हेडर होगा:

GET /data HTTP/1.1

Host: api.example.org

Referer: https://example.com/page1.html

  • शर्तें जब नहीं भेजा जाता: Referer पॉलिसी: वेबपेज कीReferrer-Policy (मेटा टैग, हेडर, या जावास्क्रिप्ट में सेट) इसे नियंत्रित करती है। उदाहरण:
  1. Referrer-Policy: no-referrer: Refererहेडर बिल्कुल नहीं भेजा जाता।
  2. Referrer-Policy: same-origin: केवल सेम-ऑरिजिन रिक्वेस्ट में भेजा जाता है।
  3. Referrer-Policy: strict-origin: केवल सुरक्षित प्रोटोकॉल (HTTPS→HTTPS) में डोमेन भेजा जाता है।
  4. HTTPS से HTTP: अगर रिक्वेस्ट HTTPS से HTTP पर जाती है, तो सुरक्षा कारणों सेReferer अक्सर नहीं भेजा जाता (ब्राउज़र नीति पर निर्भर)।
  5. मैन्युअल रिक्वेस्ट: अगर यूजर URL सीधे टाइप करता है या बुकमार्क से जाता है, तोReferer नहीं होता।
  6. गोपनीयता सेटिंग्स: कुछ ब्राउज़र (जैसे Firefox का प्राइवेट मोड) या एक्सटेंशनReferer को ब्लॉक कर सकते हैं।
  7. जावास्क्रिप्ट नियंत्रण: fetchमें { referrerPolicy: 'no-referrer' } सेट करने पर हेडर नहीं भेजा जाता।

मल्टी-डोमेन जंप में Referer में किस डोमेन का नाम आता है?

आपके सवाल का दूसरा हिस्सा: अगर दो-तीन डोमेन के बीच जंप हो (जैसे domain1.com → domain2.com → domain3.com), तो Referer हेडर में किस डोमेन का नाम आएगा—पहला या तुरंत पिछला (immediate last)?

  • जवाब: Referer हेडर में हमेशा तुरंत पिछले पेज का URL आता है (immediate last), यानी वह पेज जिसने सीधे वर्तमान रिक्वेस्ट को ट्रिगर किया। यह पहले डोमेन को ट्रैक नहीं करता, बल्कि केवल उस पेज को बताता है, जिससे रिक्वेस्ट शुरू हुई।
  • क्यों? HTTP रिक्वेस्ट स्टेटलेस होती हैं। प्रत्येक रिक्वेस्ट स्वतंत्र होती है, और ब्राउज़र केवल वर्तमान नेविगेशन के स्रोत कोReferer में शामिल करता है। ब्राउज़र पूरी नेविगेशन हिस्ट्री को ट्रैक नहीं करता; यह केवल उस पेज को भेजता है, जिसने रिक्वेस्ट को सीधे शुरू किया।

उदाहरण: मल्टी-डोमेन जंप

मान लीजिए यूजर निम्नलिखित नेविगेशन करता है:

  1. https://domain1.com→ https://domain2.com → https://domain3.com

चरण 1: domain1.com से domain2.com

  • यूजरhttps://domain1.com/page1.html पर है और एक लिंक पर क्लिक करता है जो https://domain2.com/page2.html पर ले जाता है।
  • रिक्वेस्ट:

GET /page2.html HTTP/1.1

Host: domain2.com

Referer: https://domain1.com/page1.html

  • Referer: https://domain1.com/page1.html(तुरंत पिछला पेज)।

चरण 2: domain2.com से domain3.com

  • अब यूजरhttps://domain2.com/page2.html पर है और एक लिंक पर क्लिक करता है जो https://domain3.com/page3.html पर ले जाता है।
  • रिक्वेस्ट:

GET /page3.html HTTP/1.1

Host: domain3.com

Referer: https://domain2.com/page2.html

  • Referer: https://domain2.com/page2.html(तुरंत पिछला पेज)।
  • नोट: comका कोई उल्लेख नहीं है, क्योंकि यह अब रिक्वेस्ट का सीधा स्रोत नहीं है।

चरण 3: अगर domain3.com पर API कॉल हो

  • मान लीजिएhttps://domain3.com/page3.html एक जावास्क्रिप्ट AJAX कॉल करता है https://api.domain3.com/data पर।
  • रिक्वेस्ट:

GET /data HTTP/1.1

Host: api.domain3.com

Referer: https://domain3.com/page3.html

  • Referer: https://domain3.com/page3.html(तुरंत पिछला पेज, जहां से AJAX कॉल शुरू हुआ)।

 

क्लाइंट-साइड (जावास्क्रिप्ट)

जावास्क्रिप्ट में, Referer हेडर को ब्राउज़र स्वचालित रूप से मैनेज करता है, लेकिन आप इसे नियंत्रित कर सकते हैं। उदाहरण के लिए, fetch API में referrerPolicy का उपयोग करके:

उदाहरण: Referer के साथ रिक्वेस्ट

// https://domain2.com पर चल रहा कोड

async function fetchData() {

    try {

        const response = await fetch('https://domain3.com/api/data', {

            method: 'GET',

            headers: {

                'Content-Type': 'application/json'

            }

            // डिफ़ॉल्ट रूप से referrerPolicy: 'strict-origin-when-cross-origin'

        });

 

        if (!response.ok) {

            throw new Error('Network response was not ok');

        }

 

        const data = await response.json();

        console.log(data);

    } catch (error) {

        console.error('Error fetching data:', error);

    }

}

 

fetchData();

क्या हो रहा है?

  • ब्राउज़रReferer: https://domain2.com/page2.html जोड़ता है, क्योंकि रिक्वेस्ट com से शुरू हुई।
  • अगर आपreferrerPolicy: 'no-referrer' सेट करते हैं:

fetch('https://domain3.com/api/data', {

    referrerPolicy: 'no-referrer'

});

  • तबReferer हेडर बिल्कुल नहीं भेजा जाएगा।

HTML लिंक में नियंत्रण

HTML में लिंक के लिए referrerpolicy विशेषता का उपयोग करें:

<!-- https://domain1.com पर -->

<a href="https://domain2.com" referrerpolicy="no-referrer">Go to Domain2</a>

  • यह सुनिश्चित करता है किcom पर रिक्वेस्ट में Referer हेडर नहीं होगा।

 

सर्वर-साइड (C# - ASP.NET Core)

सर्वर पर, आप Referer हेडर को पढ़ सकते हैं ताकि यह पता लगाया जाए कि रिक्वेस्ट कहां से आई। उदाहरण के लिए, domain3.com पर C# कोड:

using Microsoft.AspNetCore.Mvc;

namespace Domain3.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class DataController : ControllerBase

    {

        [HttpGet]

        public IActionResult Get()

        {

            // Referer हेडर पढ़ें

            string referer = Request.Headers["Referer"].ToString();

            if (string.IsNullOrEmpty(referer))

            {

                referer = "No Referer";

            }

 

            return Ok(new

            {

                Message = "Data from Domain3",

                Referer = referer

            });

        }

    }

}

क्या हो रहा है?

  • अगर रिक्वेस्टhttps://domain2.com से आई, तो Referer होगा https://domain2.com/page2.html।
  • अगर कोईReferer नहीं है (जैसे no-referrer पॉलिसी के कारण), तो "No Referer" लौटाया जाएगा।

उपयोग:

  • ट्रैफिक विश्लेषण: यह जानने के लिए कि यूजरcom से आए।
  • सुरक्षा: अगर अपेक्षितReferer (जैसे com) नहीं मिलता, तो रिक्वेस्ट को ब्लॉक किया जा सकता है (CSRF रोकथाम)।

मल्टी-डोमेन जंप में व्यवहार

मान लीजिए नेविगेशन ऐसा है:

  1. https://domain1.com→ लिंक क्लिक → https://domain2.com
  2. https://domain2.com→ रीडायरेक्ट → https://domain3.com
  3. https://domain3.com→ AJAX कॉल → https://api.domain3.com

Referer का व्यवहार:

  • com पर:
    • Referer: https://domain1.com/page1.html
  • com पर(रीडायरेक्ट के बाद):
    • Referer: https://domain2.com/page2.html
    • कारण: रीडायरेक्ट में, ब्राउज़र नया रिक्वेस्ट बनाता है, और तुरंत पिछला पेज (com) Refererबनता है।
  • domain3.com पर(AJAX कॉल):
    • Referer: https://domain3.com/page3.html
    • कारण: AJAX कॉलcom के पेज से शुरू हुई।

निष्कर्ष: हर रिक्वेस्ट में Referer तुरंत पिछले पेज का URL होता है, न कि नेविगेशन चेन का पहला डोमेन।

 

रीडायरेक्ट का विशेष केस

  • अगर डोमेन के बीचHTTP रीडायरेक्ट (जैसे 301, 302) होता है:
    • प्रत्येक रीडायरेक्ट के लिए, ब्राउज़र एक नया रिक्वेस्ट बनाता है।
    • Refererमें तुरंत पिछले पेज का URL रहता है, जब तक कि Referrer-Policy इसे ब्लॉक न करे।
  • उदाहरण:
    • comएक रीडायरेक्ट भेजता है:

HTTP/1.1 302 Found

Location: https://domain3.com

  • ब्राउज़रcom पर रिक्वेस्ट भेजता है:

GET / HTTP/1.1

Host: domain3.com

Referer: https://domain2.com/page2.html


Referer-Policy का प्रभाव

डोमेन जंप में Referer को नियंत्रित करने के लिए Referrer-Policy महत्वपूर्ण है। उदाहरण:

  • com:

<meta name="referrer" content="origin">

  • comपर रिक्वेस्ट में केवल डोमेन भेजा जाएगा:

Referer: https://domain1.com

  • com:

<meta name="referrer" content="no-referrer">

  • comपर रिक्वेस्ट में कोई Referer नहीं होगा।

C# में जांच:

 [HttpGet]

public IActionResult Get()

{

    string referer = Request.Headers["Referer"].ToString();

    return Ok(new { Referer = referer ?? "None" });

}

जावास्क्रिप्ट में नियंत्रण:

fetch('https://domain3.com', {

    referrerPolicy: 'same-origin' // केवल सेम-ऑरिजिन में Referer भेजें

});

आधुनिक संदर्भ

  • गोपनीयता: आधुनिक ब्राउज़र (जैसे Chrome, Firefox) डिफ़ॉल्ट रूप सेstrict-origin-when-cross-origin पॉलिसी का उपयोग करते हैं, जो क्रॉस-डोमेन रिक्वेस्ट में केवल डोमेन भेजता है (पूरा URL नहीं)।
  • HTTPS: HTTPS→HTTP रिक्वेस्ट मेंReferer अक्सर छिपाया जाता है।
  • ट्रैकिंग रोकथाम: कुछ ब्राउज़र और एक्सटेंशनReferer को सीमित करते हैं।
  • CORS के साथ: Refererऔर Origin अलग-अलग हैं। Origin केवल डोमेन (और पोर्ट) बताता है, जबकि Referer पूरा URL दे सकता है।

हमारी बातचीत से संबंध

  • हमने पहलेOrigin हेडर पर चर्चा की, जो CORS के लिए डोमेन की उत्पत्ति बताता है। Referer इससे अलग है, क्योंकि यह स्रोत पेज का पूरा URL देता है और ट्रैकिंग/सुरक्षा के लिए उपयोग होता है।
  • क्याReferer क्रॉस-डोमेन पर भेजा जाता है और मल्टी-डोमेन जंप में क्या होता है? यह तुरंत पिछले पेज को दर्शाता है।

संक्षेप में

  • क्या Referer क्रॉस-डोमेन पर भेजा जाता है?: हां, आमतौर पर ब्राउज़रReferer हेडर भेजता है, जिसमें उस पेज का URL होता है, जिससे रिक्वेस्ट शुरू हुई, जब तक कि Referrer-Policy इसे ब्लॉक न करे।
  • मल्टी-डोमेन जंप में: Refererमें तुरंत पिछले पेज (immediate last) का URL आता है, न कि नेविगेशन चेन का पहला डोमेन। उदाहरण:
    • com→ domain2.com: Referer: https://domain1.com/...
    • com→ domain3.com: Referer: https://domain2.com/...
  • C# (सर्वर): Headers["Referer"]से इसे पढ़ा जा सकता है।
  • जावास्क्रिप्ट (क्लाइंट): fetchया HTML में referrerPolicy से इसे नियंत्रित किया जा सकता है।
  • सीमाएं: Referrer-Policy, गोपनीयता सेटिंग्स, या HTTPS→HTTP रिक्वेस्ट इसे प्रभावित कर सकते हैं।


टिप्पणियाँ

एक टिप्पणी भेजें

इस ब्लॉग से लोकप्रिय पोस्ट

Differences between in-process and out-of-process hosting models

ASP.NET Core: इन-प्रोसेस और आउट-ऑफ-प्रोसेस होस्टिंग मॉडल में अंतर ASP.NET Core में सेल्फ-होस्टिंग मॉडल और आउट-प्रोसेस होस्टिंग मॉडल दो अलग-अलग तरीके हैं जिनका उपयोग आप अपने वेब एप्लिकेशन को होस्ट करने के लिए कर सकते हैं। सेल्फ-होस्टिंग मॉडल सेल्फ-होस्टिंग मॉडल में, ASP.NET Core एप्लिकेशन अपने आप में एक वेब सर्वर की भूमिका निभाता है। इसका मतलब है कि एप्लिकेशन अपने आप HTTP रिक्वेस्ट को सीधे हैंडल करता है और उन्हें प्रोसेस करता है। सेल्फ-होस्टिंग के लिए Kestrel नामक एक क्रॉस-प्लेटफ़ॉर्म वेब सर्वर का उपयोग किया जाता है। आउट-प्रोसेस होस्टिंग मॉडल आउट-प्रोसेस होस्टिंग मॉडल में, ASP.NET Core एप्लिकेशन एक अलग प्रोसेस में चलता है, और एक बाहरी वेब सर्वर (जैसे कि आईआईएस या एनजिनएक्स) HTTP रिक्वेस्ट को प्राप्त करता है और उन्हें एप्लिकेशन को फॉरवर्ड करता है। इस मॉडल में, एप्लिकेशन और वेब सर्वर अलग-अलग प्रोसेस में चलते हैं। अब इनके बारे में विस्तार से समझते हैं - 1. इन-प्रोसेस होस्टिंग (In-Process Hosting) कार...
Read more »

Web Fundamental Concepts in Hindi for Beginners - FAQs with their Answers Part-1

List of Consolidated Questions Question 1. वेब एप्लीकेशन को होस्ट करने की आवश्यकता होती है जबकि डेस्कटॉप एप्लीकेशन के साथ ऐसा नहीं होता है ऐसा क्यों? Question 2. वेब एप्लीकेशन को होस्ट करने के लिए एक वेब सर्वर की जरूरत होती है क्यों? इसके अलावा वेब एप्लीकेशन को डाटाबेस सर्वर की भी आवश्यकता पड़ती है क्यों? Question 3. वेब सर्वर के अलावा और किन-किन प्रकार के सर्वर की आवश्यकता वेब एप्लीकेशन को पड़ती है? Question 4. एक वेब एप्लीकेशन को एक से अधिक सर्वर पर कई बार क्यों होस्ट किया जाता है? Question 5. वेब एप्लीकेशन और वेब सेवा में क्या अंतर है या दोनों एक ही चीज है? Question 6. क्या यह सच है कि एक वेब एप्लीकेशन एक या एक से अधिक वेब सेवाओं का उपयोग कर सकता है? Question 7. वेब एप्लीकेशन के संदर्भ में गेटवे क्या होता है? Question 8. ...
Read more »

Introduction to ASP.NET Core and Web Frameworks

वेब एप्लीकेशन और .NET Core का परिचय वेब एप्लीकेशन हर जगह उपलब्ध हैं, चाहे वह सोशल मीडिया हो या आपका फ़ोन; हर जगह आपको वेब एप्लीकेशन दिखाई देंगे। वेब एप्लीकेशन के पीछे की दुनिया सर्वर की दुनिया है। सर्वर पर कोई वेब एप्लीकेशन होस्ट किया जाता है, तत्पश्चात वेब एप्लीकेशन रन होता है। .NET Core को आधुनिक युग की आवश्यकताओं के अनुसार डिज़ाइन किया गया है। चाहे कोई साधारण सा वेबसाइट हो या कोई जटिल ई-कॉमर्स एप्लीकेशन अथवा डिस्ट्रीब्यूटेड माइक्रो सर्विसेज, एक बार जब आप .NET Core सीख जाते हैं तो इस तरह के कोई भी एप्लीकेशन आप बना सकते हैं। अब सवाल है कि .NET Core क्या है? ASP.NET Core माइक्रोसॉफ्ट का नया वेब फ्रेमवर्क है जिसकी सहायता से विभिन्न प्रकार के वेब एप्लीकेशन को बनाना बहुत ही सरल है। माइक्रोसॉफ्ट ने ASP.NET Core को जून 2016 में रिलीज़ किया था। इसके बाद निरंतर माइक्रोसॉफ्ट की टीम ने .NET Core में सुधार करके या अपग्रेड करके बाजार में नए-नए वर्जन जारी किए हैं. वेब फ्रेमवर्क क्या है? ...
Read more »