इस पेज का अनुवाद Cloud Translation API से किया गया है.

Reporting API v1 पर माइग्रेट करें

Reporting API का नया वर्शन उपलब्ध है. यह ज़्यादा निजी है और ज़्यादातर ब्राउज़र पर काम करने की संभावना है.

Maud Nalpas

Reporting API से आपको उन गड़बड़ियों की जानकारी मिलती है जो आपकी साइट पर आने वाले लोगों के इस्तेमाल के दौरान होती हैं. इससे आपको ब्राउज़र के इंटरवेंशन, ब्राउज़र के क्रैश होने, Content-Security-Policy के उल्लंघनों, COOP/COEP के उल्लंघनों, बंद होने की चेतावनियों वगैरह के बारे में जानकारी मिलती है.

Reporting API का नया वर्शन उपलब्ध है. नया एपीआई, कम डेटा का इस्तेमाल करता है. साथ ही, इसकी ज़्यादा संभावना है कि यह सभी ब्राउज़र पर काम करे.

खास जानकारी

साइट डेवलपर

अगर आपकी साइट के लिए पहले से ही रिपोर्टिंग की सुविधा मौजूद है, तो नए हेडर (Reporting-Endpoints) का इस्तेमाल करके, v1 पर माइग्रेट करें. हालांकि, लेगसी हेडर को कुछ समय के लिए बनाए रखें (Report-To). माइग्रेशन: कोड का उदाहरण देखें.

अगर आपको अभी अपनी साइट में रिपोर्टिंग की सुविधा जोड़नी है, तो सिर्फ़ नए हेडर (Reporting-Endpoints) का इस्तेमाल करें.

⚠️ दोनों ही मामलों में, पक्का करें कि आपने उन सभी रिस्पॉन्स पर Reporting-Endpoints हेडर को सेट किया हो जो रिपोर्ट जनरेट कर सकते हैं.

रिपोर्टिंग सेवा के डेवलपर

अगर आपके पास एंडपॉइंट सेवा मैनेज करने या अपनी सेवा चलाने की ज़िम्मेदारी है, तो आपको ज़्यादा ट्रैफ़िक मिल सकता है. ऐसा इसलिए, क्योंकि आप या बाहरी डेवलपर, Reporting API v1 (Reporting-Endpoints हेडर) पर माइग्रेट कर रहे हैं.

ज़्यादा जानकारी और कोड के उदाहरण के लिए, पढ़ना जारी रखें!

नेटवर्क की गड़बड़ी की लॉगिंग

चेतावनी: अगर नेटवर्क गड़बड़ी की जानकारी को लॉग करने की सुविधा का इस्तेमाल किया जा रहा है, तो Report-To (v0) का इस्तेमाल जारी रखें. ऐसा इसलिए, क्योंकि Reporting API के वर्शन 1 में नेटवर्क गड़बड़ी की जानकारी को लॉग करने की सुविधा काम नहीं करती.

नेटवर्क से जुड़ी गड़बड़ी को लॉग करने के लिए, एक नया तरीका विकसित किया जाएगा. यह सुविधा उपलब्ध होने के बाद, Reporting API के वर्शन 0 से नए तरीके पर स्विच करें.

डेमो और कोड

डेमो साइट: नया Reporting API (v1)
डेमो साइट का कोड

v0 और v1 के बीच अंतर

क्या बदल रहा है

एपीआई का प्लैटफ़ॉर्म अलग है.

v0 (लेगसी)

 Report-To: { group: "main-endpoint", "max_age": 86400, "endpoints": [ { "url": ... }, { "url": ... }] }, { group: "default-endpoint", "max_age": 86400, "endpoints": [ { "url": ... }, { "url": ... }] }
 Document-Policy: ...; report-to main-endpoint

{0, नाम वाले एंडपॉइंट ग्रुप को कॉन्फ़िगर करने के लिए Report-To हेडर का इस्तेमाल करता है. साथ ही, इन एंडपॉइंट ग्रुप का रेफ़रंस देने के लिए, अन्य हेडर में report-to डायरेक्टिव का इस्तेमाल करता है.

v1 (नया)

 Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
 Document-Policy: ...; report-to main-endpoint

v1, named endpoints को कॉन्फ़िगर करने के लिए Reporting-Endpoints हेडर का इस्तेमाल करता है. v0 की तरह, यह इन एंडपॉइंट ग्रुप का रेफ़रंस देने के लिए, दूसरे हेडर में report-to डायरेक्टिव का इस्तेमाल करता है.

रिपोर्ट का दायरा अलग है.

v0 (लेगसी)

v0 में, सिर्फ़ कुछ जवाबों के लिए रिपोर्टिंग एंडपॉइंट सेट किए जा सकते हैं. उस ऑरिजिन के अन्य दस्तावेज़ (पेज), इन ऐंबियंट एंडपॉइंट का अपने-आप इस्तेमाल करेंगे.

v1 (नया)

v1 के साथ, आपको उन सभी रिस्पॉन्स पर Reporting-Endpoints हेडर सेट करना होगा जिनसे रिपोर्ट जनरेट हो सकती हैं.

दोनों एपीआई, एक जैसे रिपोर्ट टाइप के साथ काम करते हैं. इसका एक अपवाद है: v1 पर नेटवर्क की गड़बड़ी की रिपोर्ट काम नहीं करती. ज़्यादा जानकारी के लिए, डेटा को दूसरी जगह भेजने के तरीके लेख पढ़ें.
v0 वर्शन, सभी ब्राउज़र पर काम नहीं करता और आने वाले समय में भी नहीं करेगा. हालांकि, आने वाले समय में v1 वर्शन, कई ब्राउज़र पर काम कर सकता है.

क्या नहीं बदला जा सकता है

रिपोर्ट के फ़ॉर्मैट और स्ट्रक्चर में कोई बदलाव नहीं किया गया है.
ब्राउज़र से एंडपॉइंट पर भेजा गया अनुरोध, Content-type के लिए POST का अनुरोध बना रहता है application/reports+json.
कुछ खास एंडपॉइंट को कुछ खास रिपोर्ट टाइप से मैप करने की सुविधा, v0 और v1, दोनों में काम करती है.
default एंडपॉइंट की भूमिका में कोई बदलाव नहीं हुआ है.
Reporting API के वर्शन 1 का ReportingObserver पर कोई असर नहीं पड़ेगा. ReportingObserver को, मॉनिटर की जा सकने वाली सभी रिपोर्ट का ऐक्सेस मिलता रहेगा और उनका फ़ॉर्मैट एक जैसा है.

v0 और v1 के बीच के सभी अंतर

	लेगसी Reporting API (v0) `Report-To` हेडर	नया Reporting API (v1) `Reporting-Endpoints` हेडर
ब्राउज़र समर्थन	Chrome 69 और इसके बाद के वर्शन और Edge 69 और इसके बाद के वर्शन.	Chrome 96 और इसके बाद के वर्शन और Edge 96 और इसके बाद के वर्शन. Firefox पर भी यह सुविधा काम करती है. Safari कोई विरोध नहीं करता. ब्राउज़र सिग्नल देखें.
एंडपॉइंट	रिपोर्ट को एक से ज़्यादा रिपोर्ट कलेक्टर (हर एंडपॉइंट ग्रुप के लिए तय किए गए कई यूआरएल) में से किसी एक को भेजता है.	खास रिपोर्ट कलेक्टर को रिपोर्ट भेजता है (हर एंडपॉइंट के लिए सिर्फ़ एक यूआरएल तय किया जाता है).
एपीआई प्लैटफ़ॉर्म	नाम वाले एंडपॉइंट ग्रुप को कॉन्फ़िगर करने के लिए, `Report-To` हेडर का इस्तेमाल करता है.	यह एंडपॉइंट नाम को कॉन्फ़िगर करने के लिए, `Reporting-Endpoints` हेडर का इस्तेमाल करता है.
इस एपीआई की मदद से जनरेट की जा सकने वाली अलग-अलग तरह की रिपोर्ट	बंद होना इंटरवेंशन क्रैश COOP/COEP कॉन्टेंट-सुरक्षा-नीति का लेवल 3 (सीएसपी लेवल 3) नेटवर्क गड़बड़ी की जानकारी देने वाली लॉगिंग (एनईएल) _{Reporting API पोस्ट में, रिपोर्ट के टाइप के बारे में ज़्यादा जानें.}	नेटवर्क गड़बड़ी लॉगिंग (NEL) के अलावा, कोई बदलाव नहीं किया गया है: नए Reporting API (v1) में यह सुविधा काम नहीं करती.
रिपोर्ट का दायरा	मूल दस्तावेज़ के तौर पर दिखाता है. किसी दस्तावेज़ के `Report-To` हेडर का असर, उस ऑरिजिन के दूसरे दस्तावेज़ों (पेजों) पर पड़ता है. हालांकि, रिपोर्ट का `url` फ़ील्ड अब भी हर दस्तावेज़ के हिसाब से अलग-अलग होता है.	दस्तावेज़. किसी दस्तावेज़ के `Reporting-Endpoints` हेडर का असर सिर्फ़ उस दस्तावेज़ पर पड़ता है. हालांकि, रिपोर्ट का `url` फ़ील्ड अब भी हर दस्तावेज़ के हिसाब से अलग-अलग होता है.
रिपोर्ट आइसोलेशन (बैचिंग)	ऐसे अलग-अलग दस्तावेज़ (पेज) या साइटें/ऑरिजिन जो एक ही समय पर रिपोर्ट जनरेट करते हैं और जिनके रिपोर्टिंग एंडपॉइंट एक ही होते हैं, उन्हें एक साथ बैच में रखा जाएगा. उन्हें एक ही मैसेज में रिपोर्टिंग एंडपॉइंट पर भेजा जाएगा.	अलग-अलग दस्तावेज़ों (पेजों) की रिपोर्ट कभी एक साथ नहीं भेजी जातीं. भले ही, एक ही ऑरिजिन के दो दस्तावेज़ (पेज) एक ही समय पर एक ही एंडपॉइंट के लिए रिपोर्ट जनरेट करें, लेकिन इन्हें एक साथ नहीं भेजा जाएगा. यह निजता हमलों को कम करने का एक तरीका है. एक ही दस्तावेज़ (पेज) की रिपोर्ट एक साथ भेजी जा सकती हैं.
लोड बैलेंसिंग / प्राथमिकताओं के लिए सहायता	हां	नहीं

एंडपॉइंट डेवलपर: ज़्यादा ट्रैफ़िक की उम्मीद करें

अगर आपने खुद का सर्वर, रिपोर्टिंग एंडपॉइंट के तौर पर सेट अप किया है या सेवा के तौर पर रिपोर्ट कलेक्टर को डेवलप किया या मैनेज किया है, तो उस एंडपॉइंट पर ज़्यादा ट्रैफ़िक की उम्मीद की जा सकती है.

ऐसा इसलिए होता है, क्योंकि रिपोर्ट को Reporting API v1 के साथ बैच में नहीं भेजा जाता, क्योंकि Reporting API v0 में रिपोर्ट को इसमें शामिल किया जाता है. इसलिए, ऐप्लिकेशन डेवलपर के Reporting API v1 पर माइग्रेट करने के बाद, रिपोर्ट की संख्या पहले जैसी ही रहेगी. हालांकि, एंडपॉइंट सर्वर पर अनुरोधों की संख्या बढ़ जाएगी.

ऐप्लिकेशन डेवलपर: `Reporting-Endpoints` (v1) पर माइग्रेट करना

ऐसे में आपको क्या करना चाहिए?

Reporting API के नए वर्शन (v1) का इस्तेमाल करने के कई फ़ायदे हैं ✅:

ब्राउज़र सिग्नल पॉज़िटिव हैं. इसका मतलब है कि वर्शन 1 के लिए, अलग-अलग ब्राउज़र पर काम करने की सुविधा मिल सकती है. यह सुविधा वर्शन 0 के लिए नहीं मिलती, जो सिर्फ़ Chrome और Edge पर काम करता है.
एपीआई बेहतर है.
टूल को नए Reporting API (v1) के आधार पर डेवलप किया जा रहा है.

इन बातों को ध्यान में रखें:

अगर आपकी साइट पहले से ही Report-To हेडर के साथ Reporting API v0 का इस्तेमाल करती है, तो Reporting API v1 पर माइग्रेट करें. इसके लिए, डेटा को दूसरी जगह भेजने का तरीका देखें. अगर आपकी साइट पर पहले से ही, कॉन्टेंट की सुरक्षा के बारे में नीति के उल्लंघनों की शिकायत करने की सुविधा का इस्तेमाल किया जा रहा है, तो सीएसपी रिपोर्टिंग के लिए माइग्रेशन के खास चरणों को देखें.
अगर आपकी साइट पर पहले से ही Reporting API का इस्तेमाल नहीं किया जा रहा है और अब आपको रिपोर्टिंग की सुविधा जोड़नी है, तो: Reporting API के नए वर्शन (v1) (Reporting-Endpoints हेडर) का इस्तेमाल करें. इसमें एक अपवाद है: अगर आपको नेटवर्क गड़बड़ी को लॉग करने की सुविधा का इस्तेमाल करना है, तो Report-To (v0) का इस्तेमाल करें. फ़िलहाल, Reporting API v1 में नेटवर्क गड़बड़ी की जानकारी को लॉग करने की सुविधा काम नहीं करती. नेटवर्क से जुड़ी गड़बड़ी को लॉग करने के लिए, एक नया तरीका विकसित किया जाएगा⏤जब तक यह उपलब्ध नहीं हो जाता, तब तक Reporting API के वर्शन 0 का इस्तेमाल करें. अगर आपको अन्य तरह की रिपोर्ट के साथ-साथ नेटवर्क की गड़बड़ी लॉग करने की ज़रूरत है, तो दोनों Report-To (v0) और Reporting-Endpoints (v1) का इस्तेमाल करें. v0 से आपको नेटवर्क की गड़बड़ी को लॉग करने की सुविधा मिलती है और v1 से आपको दूसरी सभी तरह की रिपोर्ट मिलती हैं.

माइग्रेट करने का तरीका

इस माइग्रेशन का मकसद, v0 में मिलने वाली रिपोर्ट को न खोना है.

पहला चरण (अभी करें): दोनों हेडर का इस्तेमाल करें: Report-To (v0) और Reporting-Endpoints (v1).

इससे आपको ये फ़ायदे मिलते हैं:
- Reporting-Endpoints (v1) की मदद से, नए Chrome और Edge क्लाइंट से मिलने वाली रिपोर्ट.
- Chrome और Edge के पुराने क्लाइंट की रिपोर्ट, Report-To (v0) की मदद से मिली.
Reporting-Endpoints के साथ काम करने वाले ब्राउज़र इंस्टेंस, Reporting-Endpoints का इस्तेमाल करेंगे. साथ ही, उन इंस्टेंस का इस्तेमाल करेंगे जो Report-To पर फ़ॉलबैक नहीं करेंगे. अनुरोध और रिपोर्ट का फ़ॉर्मैट, v0 और v1 के लिए एक जैसा है.
दूसरा चरण (अभी करें): पक्का करें कि Reporting-Endpoints हेडर को उन सभी रिस्पॉन्स पर सेट किया गया हो जिनसे रिपोर्ट जनरेट हो सकती हैं.

v0 में, सिर्फ़ कुछ जवाबों पर रिपोर्टिंग एंडपॉइंट सेट करने का विकल्प चुना जा सकता है. साथ ही, उस ऑरिजिन के अन्य दस्तावेज़ (पेज), इस "ऐंबियंट" एंडपॉइंट का इस्तेमाल करेंगे. v1 के लिए, अलग-अलग दायरों की वजह से, आपको उन सभी रिस्पॉन्स के लिए Reporting-Endpoints हेडर सेट करना होगा जो रिपोर्ट जनरेट कर सकते हैं.
तीसरा चरण (बाद में शुरू करें): जब आपके सभी या ज़्यादातर उपयोगकर्ता, Chrome या Edge इंस्टॉल (96 और इसके बाद के) पर अपडेट हो जाएं, तब Report-To (v0) को हटाएं और सिर्फ़ Reporting-Endpoints रखें.

एक अपवाद: अगर आपको नेटवर्क गड़बड़ी की लॉगिंग रिपोर्ट की ज़रूरत है, तो नेटवर्क गड़बड़ी की लॉगिंग के लिए नया तरीका लागू होने तक Report-To को सेट करें.

माइग्रेशन कुकबुक में कोड के उदाहरण देखें.

सीएसपी रिपोर्टिंग के लिए माइग्रेशन का तरीका

Content-Security-Policy के उल्लंघन की रिपोर्ट को कॉन्फ़िगर करने के दो तरीके हैं:

report-uri डायरेक्टिव की मदद से, सिर्फ़ CSP हेडर के साथ. यह सुविधा Chrome, Firefox, Safari, और Edge जैसे कई ब्राउज़र पर काम करती है. रिपोर्ट, कॉन्टेंट-टाइप application/csp-report के साथ भेजी जाती हैं और उनका फ़ॉर्मैट, सीएसपी के हिसाब से होता है. इन रिपोर्ट को "सीएसपी लेवल 2 रिपोर्ट" कहा जाता है. ये रिपोर्ट, Reporting API पर नहीं निर्भर करती हैं.
Reporting API की मदद से, Report-To हेडर (लेगसी) या नए Reporting-Endpoints (v1) के ज़रिए. यह सुविधा सिर्फ़ Chrome और Edge पर काम करती है. रिपोर्ट के अनुरोधों का फ़ॉर्मैट, Reporting API के अन्य अनुरोधों जैसा ही होता है. साथ ही, इनका कॉन्टेंट टाइप भी application/reports+json होता है.

पहले तरीके (सिर्फ़ report-uri) का इस्तेमाल करने का अब सुझाव नहीं दिया जाता. वहीं, दूसरे तरीके का इस्तेमाल करने के कुछ फ़ायदे हैं. खास तौर पर, इससे आपको सभी तरह की रिपोर्ट के लिए रिपोर्टिंग सेट अप करने के एक ही तरीके का इस्तेमाल करने के साथ-साथ एक सामान्य एंडपॉइंट सेट करने में मदद मिलती है. ऐसा इसलिए, क्योंकि Reporting API⏤CSP से जनरेट होने वाले सभी रिपोर्ट अनुरोधों का फ़ॉर्मैट application/reports+json एक ही होता है और अन्य.

हालांकि, सिर्फ़ कुछ ब्राउज़र पर report-to काम करता है. इसलिए, हमारा सुझाव है कि आप Reporting API के तरीके (Report-To या बेहतर तरीके से, Reporting-Endpoints) के साथ-साथ report-uri का इस्तेमाल करें, ताकि आपको कई ब्राउज़र से सीएसपी के उल्लंघन की रिपोर्ट मिल सकें. report-uri और report-to की पहचान करने वाले ब्राउज़र में, अगर report-to मौजूद है, तो report-uri को अनदेखा कर दिया जाएगा. अगर किसी ब्राउज़र में सिर्फ़ report-uri को पहचाना जाता है, तो सिर्फ़ report-uri को ही स्वीकार किया जाएगा.

पहला चरण (अभी करें): अगर आपने अब तक report-uri के साथ report-to नहीं जोड़ा है, तो उसे जोड़ें. सिर्फ़ report-uri (Firefox) के साथ काम करने वाले ब्राउज़र, report-uri का इस्तेमाल करेंगे. वहीं, report-to (Chrome, Edge) के साथ काम करने वाले ब्राउज़र, report-to का इस्तेमाल करेंगे. नाम वाले जिन एंडपॉइंट का इस्तेमाल आपको report-to में करना है उनके बारे में बताने के लिए, Report-To और Reporting-Endpoints, दोनों हेडर का इस्तेमाल करें. इससे यह पक्का होता है कि आपको Chrome और Edge के पुराने और नए, दोनों क्लाइंट से रिपोर्ट मिलती हैं.
तीसरा चरण (बाद में शुरू करें): जब आपके सभी या ज़्यादातर उपयोगकर्ता, Chrome या Edge इंस्टॉल (96 और इसके बाद के) पर अपडेट हो जाएं, तब Report-To (v0) को हटाएं और सिर्फ़ Reporting-Endpoints रखें. report-uri को बनाए रखें, ताकि आपको अब भी उन ब्राउज़र की रिपोर्ट मिलें जिन पर यह सुविधा काम करती है.

सीएसपी रिपोर्टिंग माइग्रेशन में, इन चरणों के लिए कोड के उदाहरण देखें.

माइग्रेशन: कोड का उदाहरण

खास जानकारी

अगर आपने सीओओपी (Cross-Origin-Opener-Policy हेडर), सीओईपी (Cross-Origin-Embedder-Policy) या दस्तावेज़ नीति (Document-Policy हेडर) के उल्लंघन की रिपोर्ट पाने के लिए, Reporting API के लेगसी वर्शन (v0) का इस्तेमाल किया है, तो आपको Reporting API के वर्शन 1 पर माइग्रेट करते समय, इन नीति हेडर को खुद बदलने की ज़रूरत नहीं है. आपको Report-To के लेगसी हेडर से नए Reporting-Endpoints हेडर पर माइग्रेट करना होगा.

अगर किसी सीएसपी (Content-Security-Policy हेडर) के लिए, नीति के उल्लंघन की रिपोर्ट पाने के लिए, Reporting API के लेगसी वर्शन (v0) का इस्तेमाल किया जा रहा है, तो आपको Reporting API के नए वर्शन (v1) पर माइग्रेट करने के लिए, अपने Content-Security-Policy में बदलाव करना पड़ सकता है.

बुनियादी माइग्रेशन

लेगसी कोड (v0 के साथ)

Report-To: { group: "main-endpoint", "endpoints": [ { "url": "https://reports.example/main" }] }, { group: "default-endpoint", "endpoints": [ { "url": "https://reports.example/default" }] }

नया कोड (v1 के साथ-साथ v0 वाला ट्रांज़िशन कोड)

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: { group: "main-endpoint", "max_age": 86400, "endpoints": [ { "url": "https://reports.example/main" }] }, { group: "default-endpoint", "max_age": 86400, "endpoints": [ { "url": "https://reports.example/default" }] }

अगर आपकी साइट में पहले से ही रिपोर्टिंग की सुविधा उपलब्ध है, तो रिपोर्ट सेव रखने के लिए, Report-To को सिर्फ़ कुछ समय के लिए (ज़्यादातर Chrome और Edge क्लाइंट के अपडेट होने तक) रखें.

अगर आपको नेटवर्क लॉगिंग की सुविधा चाहिए, तो Report-To को तब तक चालू रखें, जब तक नेटवर्क लॉगिंग की सुविधा का विकल्प उपलब्ध नहीं हो जाता.

नया कोड (सिर्फ़ v1 के साथ)

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

आने वाले समय में, Chrome और Edge के ज़्यादातर क्लाइंट अपडेट हो जाने और एपीआई v1 के साथ काम करने के बाद, आपका कोड ऐसा दिख सकता है.

ध्यान दें कि v1 में, अब भी खास एंडपॉइंट पर खास रिपोर्ट टाइप भेजे जा सकते हैं. हालांकि, हर एंडपॉइंट के लिए सिर्फ़ एक यूआरएल हो सकता है.

सभी पेजों को देखना

लेगसी कोड (v0 के साथ), जैसे कि एक्सप्रेस के साथ

app.get("/", (request, response) => {
  response.set("Report-To", …)
  response.render(...)
});
app.get("/page1", (request, response) => {
  response.render(...)
});

v0 में, सिर्फ़ कुछ जवाबों के लिए रिपोर्टिंग एंडपॉइंट सेट किए जा सकते हैं. उस ऑरिजिन के अन्य दस्तावेज़ (पेज), इन ऐंबियंट एंडपॉइंट का अपने-आप इस्तेमाल करते हैं. यहां, "/" के लिए सेट किए गए एंडपॉइंट का इस्तेमाल सभी रिस्पॉन्स के लिए किया जाता है. उदाहरण के लिए, page1 के लिए.

नया कोड (v1 के साथ), जैसे कि Express के साथ

// Use a middleware to set the reporting endpoint(s) for *all* requests.
app.use(function(request, response, next) {
  response.set("Reporting-Endpoints", …);
  next();
});

app.get("/", (request, response) => {
  response.render(...)
});

app.get("/page1", (request, response) => {
  response.render(...)
});

v1 वर्शन में, आपको रिपोर्ट जनरेट करने वाले सभी रिस्पॉन्स के लिए Reporting-Endpoints हेडर सेट करना होगा.

सीएसपी रिपोर्टिंग माइग्रेशन

सिर्फ़ report-uri वाला लेगसी कोड

Content-Security-Policy: ...; report-uri https://reports.example/main

report-uri का इस्तेमाल करने का सुझाव अब नहीं दिया जाता. अगर आपका कोड ऊपर दिए गए कोड जैसा दिखता है, तो माइग्रेट करें. नीचे दिए गए नए कोड के उदाहरण देखें (हरे रंग में).

बेहतर लेगसी कोड, जिसमें report-uri और report-to डायरेक्टिव के साथ Report-To (v0) हेडर है

Content-Security-Policy: ...; report-uri https://reports.example/main; report-to main-endpoint
Report-To: main-endpoint="https://reports.example/main"

यह बेहतर है: यह कोड, report-to का इस्तेमाल करता है. यह report-uri की जगह, नया विकल्प है. यह अब भी पुराने सिस्टम के साथ काम करने के लिए report-uri को सेव रखता है. कई ब्राउज़र पर यह काम नहीं करता report-to लेकिन काम करता है report-uri.

हालांकि, इसे और बेहतर बनाया जा सकता है: यह कोड, Reporting API v0 (Report-To हेडर) का इस्तेमाल करता है. v1 पर माइग्रेट करें: नीचे दिए गए 'नया कोड' के उदाहरण देखें (हरे रंग में).

Reporting-Endpoints (v1) हेडर के साथ report-uri और report-to डायरेक्टिव वाला नया कोड

Content-Security-Policy: ...; report-uri https://reports.example/main; report-to main-endpoint
Reporting-Endpoints: main-endpoint="https://reports.example/main"
Report-To: ...

report-uri डायरेक्टिव को report-to डायरेक्टिव के बगल में तब तक रखें, जब तक report-to डायरेक्टिव सभी ब्राउज़र पर काम न करता हो. अलग-अलग ब्राउज़र पर साइट की जांच करने के लिए बनी टेबल देखें.

Report-To को कुछ समय के लिए Reporting-Endpoints के साथ रखें. जब आपके Chrome और Edge का इस्तेमाल करने वाले ज़्यादातर लोग, ब्राउज़र के 96 और उसके बाद के वर्शन पर अपग्रेड कर लें, तब Report-To को हटा दें.

इसके बारे में और पढ़ें

Reporting API की मदद से अपने वेब ऐप्लिकेशन को मॉनिटर करना (Reporting API के बारे में मुख्य पोस्ट)
स्पेसिफ़िकेशन: Reporting API का लेगसी वर्शन (v0)
स्पेसिफ़िकेशन: नया Reporting API (v1)

इस लेख पर अपनी समीक्षाएं और सुझाव देने के लिए, इयान क्लेलैंड, एइजी कितामुरा, और मिलिका मिहाइलिया का बहुत-बहुत धन्यवाद.

Reporting API v1 पर माइग्रेट करें

खास जानकारी

साइट डेवलपर

रिपोर्टिंग सेवा के डेवलपर

नेटवर्क की गड़बड़ी की लॉगिंग

डेमो और कोड

v0 और v1 के बीच अंतर

क्या बदल रहा है

क्या नहीं बदला जा सकता है

एंडपॉइंट डेवलपर: ज़्यादा ट्रैफ़िक की उम्मीद करें

ऐप्लिकेशन डेवलपर: Reporting-Endpoints (v1) पर माइग्रेट करना

ऐसे में आपको क्या करना चाहिए?

माइग्रेट करने का तरीका

सीएसपी रिपोर्टिंग के लिए माइग्रेशन का तरीका

माइग्रेशन: कोड का उदाहरण

खास जानकारी

बुनियादी माइग्रेशन

सभी पेजों को देखना

सीएसपी रिपोर्टिंग माइग्रेशन

इसके बारे में और पढ़ें

ऐप्लिकेशन डेवलपर: `Reporting-Endpoints` (v1) पर माइग्रेट करना