कस्टम HTTP हेडर: नामकरण परंपराएँ

1113

हमारे कई उपयोगकर्ताओं ने हमें हमारे द्वारा भेजे गए अनुरोधों के HTTP हेडर में उनके खाते के सापेक्ष डेटा शामिल करने के लिए कहा है , या यहां तक कि प्रतिक्रियाएं भी जो उन्हें हमारे एपीआई से मिलती हैं। नामकरण , प्रारूप ... आदि के संदर्भ में, कस्टम HTTP हेडर जोड़ने के लिए सामान्य सम्मेलन क्या है ।

इसके अलावा, बेझिझक इनमें से किसी भी स्मार्ट उपयोग को पोस्ट करें जो आपने वेब पर ठोकर खाई थी; हम इसे लागू करने की कोशिश कर रहे हैं जो एक लक्ष्य के रूप में सबसे अच्छा है :)

http http-headers

— जूलियन जेनस्टौक्स
स्रोत

25

ध्यान रखें कि फ़ायरवॉल प्रतिक्रिया हेडर फ़ील्ड को निकाल सकता है। कुछ RFC 2616 (जून 1999, HTTP 1.1) में उल्लेखित नहीं हैं। नए क्षेत्रों के बिना क्लाइंट पक्ष अभी भी प्रयोग करने योग्य होना चाहिए।

— stesch

5

ध्यान दें कि @stesch द्वारा टिप्पणी HTTP S का उपयोग करते समय लागू नहीं होती है ।

— code_dredd

1

ध्यान दें कि @code_dredd द्वारा टिप्पणी एक शहरी किंवदंती है। फ़ायरवॉल HTTPS सामग्री को फ़िल्टर कर सकते हैं। देखें howtoforge.com/filtering-https-traffic-with-squid और watchguard.com/help/docs/wsm/xtm_11/en-us/content/en-us/...

— stesch

@stesch यह देखते हुए कि आपका लेख मूल रूप से प्रॉक्सी को MiTM के समान बनाता है (यह एन्क्रिप्टेड क्लाइंट कनेक्शन लेता है और फिर एक नया बनाता है) तो यकीन है, आप लगभग कुछ भी कर सकते हैं, लेकिन यह तथ्य प्रॉक्सी के PoV / / से एन्क्रिप्शन की उपेक्षा करता है c यह ग्राहक की सामग्री को स्वयं डिक्रिप्ट कर रहा है। उस मामले में, प्रॉक्सी के पीओवी से, यह मूल रूप से है जैसे कि आप 1 जगह में HTTPS का उपयोग नहीं कर रहे थे ...

— code_dredd

1170

सिफारिश ~~यह है~~ कि उनका नाम "X-" के साथ शुरू किया जाए। उदाहरण के लिए X-Forwarded-For, X-Requested-With। आरएफसी 2047 के एओ खंड 5 में भी इसका उल्लेख किया गया है ।

अद्यतन 1 : जून 2011 को, गैर मानक हेडर के लिए "X-" उपसर्ग का उपयोग करने की सिफारिश को चित्रित करने के लिए पहला IETF मसौदा पोस्ट किया गया था । कारण यह है कि जब गैर-मानक हेडर "एक्स-" के साथ उपसर्ग करते हैं, तो मानक बन जाते हैं, "एक्स-" उपसर्ग को हटाकर पीछे की संगतता बन जाती है, दोनों नामों (जैसे, x-gzipऔर gzipअब समतुल्य) का समर्थन करने के लिए आवेदन प्रोटोकॉल मजबूर करता है । इसलिए, आधिकारिक सिफारिश सिर्फ उन्हें "एक्स-" उपसर्ग के बिना समझदारी से नाम देना है ।

अद्यतन 2 : जून 2012 को, "X-" उपसर्ग का उपयोग करने के लिए सिफारिश का पदावनति RFC 6648 के रूप में आधिकारिक हो गया है । नीचे प्रासंगिकता का हवाला दिया गया है:

3. नए पैरामीटर के रचनाकारों के लिए सिफारिशें

...

"X-" या इसी तरह के निर्माण के साथ उनके पैरामीटर नामों को उपसर्ग न करें।

4. प्रोटोकॉल डिजाइनरों के लिए सिफारिशें

...

एक "एक्स-" उपसर्ग या पंजीकृत होने से समान निर्माण के साथ मापदंडों का निषेध नहीं करना चाहिए।

जरूरी नहीं कि "एक्स-" उपसर्ग या इसी तरह के निर्माण के साथ एक पैरामीटर को अनियंत्रित समझा जाना चाहिए।

जरूरी नहीं कि "एक्स-" उपसर्ग या इसी तरह के निर्माण के बिना एक पैरामीटर को मानकीकृत समझा जाना चाहिए।

ध्यान दें कि "SHOULD NOT" ("हतोत्साहित") "MUST NOT" ("निषिद्ध") के समान नहीं है, उन कीवर्ड पर एक और युक्ति के लिए RFC 2119 भी देखें । दूसरे शब्दों में, आप "X-" उपसर्ग हेडर का उपयोग कर सकते हैं, लेकिन यह आधिकारिक तौर पर अब अनुशंसित नहीं है और आप निश्चित रूप से उन्हें दस्तावेज नहीं कर सकते हैं जैसे कि वे सार्वजनिक मानक हैं।

सारांश :

आधिकारिक सिफारिश सिर्फ "एक्स-" उपसर्ग के बिना उन्हें समझदारी से नाम देना है
आप "X-" उपसर्ग हेडर का उपयोग कर सकते हैं, लेकिन यह आधिकारिक तौर पर अब अनुशंसित नहीं है और आप निश्चित रूप से उन्हें दस्तावेज नहीं दे सकते हैं जैसे कि वे मानक नहीं हैं

— BalusC
स्रोत

306

जैसे कि कई बच्चे हैं जो पेशेवर एथलीटों के रूप में कभी भी समाप्त नहीं होंगे, कई कस्टम हेडर कभी भी मानकों के रूप में समाप्त नहीं होंगे। मैं उन पर "X-" रखने के लिए इच्छुक हूं।

— जी-मैक

19

@ जी-मैक सहमत। कर रहे हैं तो कई कस्टम हेडर कि अंत कभी नहीं होगा मानकीकरण किया। जो कुछ करते हैं, वह आपके कोड को केवल से संपादित करना आसान if (header == "x-gzip")है if (header == "x-gzip" || header == "gzip")। अपने सादृश्य के रूप में, यहां एक और है: यह सैन्य की तरह है "ओह, यह किसी को निजी से जनरल में बदलने के लिए परेशानी है। इसलिए, अब से, आप सभी जनरलों हैं। अब हमें इतना काम करने की आवश्यकता नहीं है"

— कोल जॉनसन

24

@ColeJohnson यकीन नहीं है कि अगर सादृश्य काम करता है। यहां समस्या यह है कि कोई केंद्रीय बिंदु नहीं है जिससे आप नाम बदल सकते हैं। कोड का हर एक स्निपेट जो एक्स-गज़िप की अपेक्षा करता है उसे अब बदलना होगा, या पुराने हेडर को नए के अलावा उपयोग करने के लिए जारी रखने की आवश्यकता है। RFC 6648 के साथ जाना बेहतर है।

— विनोद

4

@ विनोद हाँ। यह समझ में आता है, लेकिन कई प्रस्तावित मानक हैं जो कभी भी दिन का प्रकाश नहीं देखेंगे। फ़ाइल प्रकारों के लिए, निश्चित रूप से; X-उपसर्ग छोड़ें । मैं इसके खिलाफ हूं, लेकिन आगे बढ़ो और इसे करो। हेडर OTOH के लिए, इसे ड्रॉप न करें। इसे देखना और जाना आसान बनाता है, "ओह, यह गैर-मानक है; मैं इसे अनदेखा कर सकता हूं" बनाम "वहाँ उन गैर-मानक X-हेडर हैं, और फिर यह वही है जिसे मैं नहीं पहचानता हूं? क्या मैं इसे सुरक्षित रूप से अनदेखा कर सकता हूं?"

— कोल जॉनसन

21

यद्यपि cweekly के उत्तर का स्वर अनावश्यक रूप से रक्षात्मक है, मेरा मानना है कि वह सही है, और उसकी बात इस टिप्पणी में वर्णित समस्या को हल करती है। संक्षेप में, यह पहचानने की कोशिश न करें कि क्या हेडर "स्नातक" होगा या नहीं; इसके बजाय यह निर्धारित करें कि क्या यह एक निजी या सार्वजनिक शीर्ष लेख (एप्लिकेशन-विशिष्ट या "सामान्य" / "वैश्विक") है। निजी हेडर के लिए, वैकल्पिक रूप X-से सार्वजनिक हेडर (RFC6648 के लिए धन्यवाद, जो सार्वजनिक हेडर से संबंधित है) के साथ कोई टकराव सुनिश्चित करने के लिए उपयोग करते हैं , और इसके अलावा निश्चित रूप से एक मनमाना निजी उपसर्ग का उपयोग करते हैं। सार्वजनिक हेडर के लिए, X-किसी भी परिस्थिति में उपयोग न करें ।

— tne

535

सवाल फिर से पढ़ना है। पूछे जाने वाले वास्तविक प्रश्न सीएसएस गुणों में विक्रेता उपसर्गों के समान नहीं है, जहां विक्रेता समर्थन और आधिकारिक मानकों के बारे में भविष्य के प्रमाण और सोच उपयुक्त है। पूछा गया वास्तविक प्रश्न URL क्वेरी पैरामीटर नामों को चुनने के लिए अधिक समान है। किसी को परवाह नहीं करनी चाहिए कि वे क्या हैं। लेकिन रिवाजों को नाम देना एक पूरी तरह से मान्य है - और सामान्य, और सही - बात करने के लिए।

तर्क:
यह कस्टम, एप्लिकेशन-विशिष्ट हेडरों के लिए डेवलपर्स के बीच सम्मेलनों के बारे में है - " डेटा उनके खाते के लिए प्रासंगिक " - जिसका वेंडर, मानक निकाय, या प्रोटोकॉल के साथ तीसरे पक्ष द्वारा लागू किए जाने से कोई लेना-देना नहीं है, सिवाय इसके कि डेवलपर सवाल में बस हेडर नामों से बचने की आवश्यकता होती है जो सर्वर, प्रॉक्सी या क्लाइंट द्वारा अन्य इच्छित उपयोग हो सकते हैं। इस कारण से, "X-Gzip / Gzip" और "X-Forwarded-For / फॉरवर्ड-फॉर" उदाहरण दिए गए हैं। सवाल यह है कि एक निजी एपीआई के संदर्भ में सम्मेलनों के बारे में है, यूआरएल क्वेरी पैरामीटर नामकरण परंपराओं के समान है। यह वरीयता और नाम-रिक्ति की बात है; "X-ClientDataFoo" के बारे में चिंताओं को "X" के बिना किसी भी प्रॉक्सी या विक्रेता द्वारा समर्थित किया जा रहा है

"X-" उपसर्ग के बारे में कुछ विशेष या जादुई नहीं है, लेकिन यह स्पष्ट करने में मदद करता है कि यह एक कस्टम हेडर है। वास्तव में, RFC-6648 et al एक "X-" उपसर्ग के उपयोग के लिए मामले को बढ़ाने में मदद करते हैं, क्योंकि - जैसे HTTP क्लाइंट और सर्वर के विक्रेता उपसर्ग को छोड़ देते हैं - आपके ऐप-विशिष्ट, निजी-एपीआई, व्यक्तिगत-डेटा- पासिंग-मैकेनिज़्म कम-से-कम आधिकारिक आरक्षित हेडर नामों की संख्या के साथ नाम-स्थान टकराव के खिलाफ बेहतर-अछूता होता जा रहा है। उस ने कहा, मेरी व्यक्तिगत प्राथमिकता और सिफारिश एक कदम और आगे बढ़ना है और उदाहरण के लिए "X-ACME-ClientDataFoo" (यदि आपकी विजेट कंपनी "ACME" है)।

ओपीओ के प्रश्न का उत्तर देने के लिए आईएमएचओ आईईटीएफ युक्ति अपर्याप्त रूप से विशिष्ट है, क्योंकि यह पूरी तरह से अलग-अलग उपयोग मामलों के बीच अंतर करने में विफल रहता है: (ए) एक तरफ, "बी" के लिए "फॉरवर्ड-फॉर" जैसी नई विश्व-स्तर पर लागू होने वाली विशेषताओं को प्रस्तुत करता है। एप्लिकेशन डेवलपर क्लाइंट और सर्वर से / से ऐप-विशिष्ट स्ट्रिंग्स पास कर रहे हैं। कल्पना केवल पूर्व, (ए) के साथ ही चिंता करती है। यहां सवाल यह है कि क्या (बी) के लिए कन्वेंशन हैं। वहां। वे मापदंडों को एक साथ वर्णानुक्रम में समूहीकृत करना और उन्हें कई प्रकार के प्रासंगिक मानकों से अलग करना शामिल करते हैं (ए)। "X-" या "X-ACME-" उपसर्ग का उपयोग करना (बी) के लिए सुविधाजनक और वैध है, और (ए) के साथ संघर्ष नहीं करता है। जितना अधिक विक्रेता (ए) के लिए "एक्स-" का उपयोग करना बंद कर देंगे, उतने ही अधिक साफ-सुथरे (बी) वाले बन जाएंगे।

उदाहरण:
Google (जो विभिन्न मानकों के निकायों में थोड़ा सा वजन उठाते हैं) हैं - आज के अनुसार, 20141102 मेरे उत्तर के लिए इस थोड़े से संपादन में - वर्तमान में "अप-मॉड-पेजस्पीड" का उपयोग करके अपने अपाचे मॉड्यूल के संस्करण को इंगित करने के लिए दी गई प्रतिक्रिया को बदलने में शामिल। क्या कोई वास्तव में यह सुझाव दे रहा है कि Google को "X-" के बिना, "मॉड-पेजस्पीड" का उपयोग करना चाहिए, और / या आईईटीएफ को इसके उपयोग को आशीर्वाद देने के लिए कहें?

सारांश:
यदि आप अपने सर्वर से / से डेटा पास करने के लिए अपने ऐप के भीतर कस्टम HTTP हेडर (कुकीज़ के लिए एक उपयुक्त विकल्प के रूप में) का उपयोग कर रहे हैं, और ये हेडर स्पष्ट रूप से हैं, तो कभी भी आपके संदर्भ के बाहर उपयोग करने का इरादा नहीं है। एक "X-" या "X-FOO-" उपसर्ग के साथ उन्हें नाम देना, उपसर्ग एक उचित, और सामान्य, सम्मेलन है।

— cweekly
स्रोत

52

अगर मेरी टिप्पणी के किसी भी व्याख्याकार ने मेरे उत्तर के किस हिस्से को आपत्तिजनक पाया, यह बता सकता हूँ। मुझे अपने प्रतिष्ठा स्कोर के बारे में इतना ध्यान नहीं है, लेकिन मैं वास्तव में उत्सुक हूं। असहमति कहाँ है? धन्यवाद।

— cweekly 19

56

मैं आपके उत्तर से पूरी तरह सहमत हूं और यहां एकमात्र उत्तर है जो पूछे गए वास्तविक प्रश्न का उत्तर देता है। हम यहां कस्टम, एप्लिकेशन-विशिष्ट हेडर के बारे में बात कर रहे हैं, कभी भी HTTP मानकों में मानकीकृत नहीं किया जाना चाहिए। क्या इनका एक आम सम्मेलन है जिसका उपयोग लोग करते हैं? (जैसे कि "_" के साथ उन्हें उपसर्ग देना शायद? (?: ("_ClientDataFoo")

— Marchy

14

धन्यवाद Marchy, हाँ, स्वीकार किए जाते हैं जवाब सवाल का पता नहीं पूछा। गैर-मानक (लेकिन सामान्य) हेडर के लिए "X-" उपसर्ग का IETF अपवर्जन कस्टम ऐप-विशिष्ट हेडर के लिए अप्रासंगिक है जो कभी भी मानकीकृत नहीं होगा। आपके प्रश्न का उत्तर देने के लिए, मेरी राय और अनुभव (वेबदेव के 16 वर्ष) में, सबसे अच्छा सम्मेलन उपरोक्त "एक्स-एसीएमई-क्लाइंटडाटा" का उपयोग करना है। "X-" bc यह मानक नहीं है (और न ही यह कभी होगा, यही कारण है कि IETF पदावनत यहाँ पर मूट है), "ACME-" इसे आपकी "ACME" कंपनी या विशिष्ट ऐप में नामांकित करने के लिए, और "ClientData" जो कुछ भी हो सकता है सिमेंटिक नाम जो आपको पसंद है। :)

— cweekly

5

@DarrelMiller ... इसलिए X-ACMECO-WIDGET-FOO का उपयोग करने की सिफारिश। मैं जोर देकर कहता हूं कि ओपी के सवाल के अनुसार, X- का उपयोग केवल RFC-6648 और इसी तरह का संकेत नहीं है। यदि आप अन्य लोगों की परियोजनाओं में उपयोग के लिए एक ढांचा, पुस्तकालय या मॉड्यूल प्रदान करने वाले विक्रेता हैं, तो यह एक अलग कहानी है, और हर तरह से आरएफसी से लेकर टी। का पालन करना है। लेकिन यह केवल व्यक्तिगत वन-ऑफ अनुप्रयोगों के लिए ही है, जहां कस्टम एप्लिकेशन-विशिष्ट हेडर नामकरण परंपराएं प्रभावी रूप से पूरी तरह से निजी एपीआई हैं। वे "हर किसी के नाम" के साथ कैसे टकराएंगे? वो किसके होंगे?

— cweekly

11

मुझे ईमानदारी से RFC तर्क को समझने में थोड़ी परेशानी हो रही है। दी है कि, अगर और जब पैरामीटर मानकीकृत है, तो दोनों x- और गैर- x- संस्करण होंगे। यह केवल एक समस्या है अगर x और गैर- x- संस्करणों का व्यवहार समान है। मैं यहाँ पर लड़खड़ा गया क्योंकि मैं अपने एपीआई के हेडर की ओर से "जोड़ने" पर देख रहा हूँ। यह किसी दिन सार्वजनिक हो सकता है (जैसा कि यह एक सामान्य प्रकार का उपयोग मामला है)। अगर मैंने "ऑन-बिफोर-ऑफ़" का इस्तेमाल किया और किसी दिन वे इसे एक मानक हेडर के रूप में जोड़ते हैं, तो ऐसी कौन सी बाधाएँ हैं जो मेरे शब्दार्थ मानकीकृत के समान होंगे?

— मूर्ख 4

62

HTTP हेडर के लिए प्रारूप HTTP विनिर्देश में परिभाषित किया गया है। मैं HTTP 1.1 के बारे में बात करने जा रहा हूं, जिसके लिए विनिर्देश RFC 2616 है । खंड ४.२, section संदेश प्रमुख ’में, हेडर की सामान्य संरचना को परिभाषित किया गया है:

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

यह परिभाषा दो मुख्य स्तंभों, टोकन और पाठ पर टिकी हुई है। दोनों को खंड 2.2, 'मूल नियम' में परिभाषित किया गया है। टोकन है:

   token          = 1*<any CHAR except CTLs or separators>

बदले में CHAR, CTL और विभाजकों पर आराम करना:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

पाठ है:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

जहां LWS लीनियर व्हाइट स्पेस है, जिसकी परिभाषा मैं पुन: पेश नहीं करूंगा, और OCTET है:

   OCTET          = <any 8-bit sequence of data>

परिभाषा के साथ एक नोट है:

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

तो, दो निष्कर्ष। सबसे पहले, यह स्पष्ट है कि हेडर नाम ASCII वर्णों के सबसेट से बना होना चाहिए - अल्फ़ान्यूमेरिक्स, कुछ विराम चिह्न, बहुत कुछ नहीं। दूसरे, हेडर मान की परिभाषा में ऐसा कुछ नहीं है जो इसे ASCII तक सीमित करता है या 8-बिट वर्णों को बाहर करता है: यह स्पष्ट रूप से ऑक्टेट्स से बना है, केवल नियंत्रण वर्णों पर ध्यान दें (सीआर और एलएफ को नियंत्रण माना जाता है)। इसके अलावा, TEXT उत्पादन पर टिप्पणी का अर्थ है कि ओसीसी -8859-1 में ऑक्टेट्स की व्याख्या की जानी है, और उस एन्कोडिंग के बाहर वर्णों का प्रतिनिधित्व करने के लिए एक एन्कोडिंग तंत्र (जो भयानक, संयोगवश) है।

तो, विशेष रूप से @BalusC पर प्रतिक्रिया देने के लिए, यह बिल्कुल स्पष्ट है कि विनिर्देश के अनुसार, हेडर मान ISO-8859-1 में हैं। मैंने टॉमकैट से बाहर एक हेडर में उच्च -8859-1 अक्षर (विशेष रूप से, कुछ उच्चारण स्वरों का इस्तेमाल किया है) भेजा है, और उन्हें फ़ायरफ़ॉक्स द्वारा सही ढंग से व्याख्या किया है, इसलिए कुछ हद तक, यह अभ्यास के साथ-साथ सिद्धांत में भी काम करता है (हालांकि यह एक स्थान शीर्षलेख था, जिसमें URL शामिल है, और ये वर्ण URL में कानूनी नहीं हैं, इसलिए यह वास्तव में अवैध था, लेकिन एक अलग नियम के तहत!)।

उस ने कहा, मैं सभी सर्वरों, प्रॉक्सी और क्लाइंट्स पर काम कर रहे ISO-8859-1 पर भरोसा नहीं करूंगा, इसलिए मैं रक्षात्मक प्रोग्रामिंग के मामले में ASCII से चिपके रहूंगा।

— टॉम एंडरसन
स्रोत

3

नया HTTP युक्ति RFC7230 कहता है, "नए परिभाषित हेडर फ़ील्ड

— रॉबर्ट टुपेलो-श्नेक

23

RFC6648 अनुशंसा करता है कि आप मानते हैं कि आपका कस्टम हेडर "मानकीकृत, सार्वजनिक, आमतौर पर तैनात, या कई कार्यान्वयनों के लिए उपयोग योग्य हो सकता है।" इसलिए, यह "एक्स-" या इसी तरह के निर्माणों के साथ इसे उपसर्ग नहीं करने की सिफारिश करता है।

हालांकि, एक अपवाद है "जब यह बेहद संभावना नहीं है कि [आपका हेडर] कभी भी मानकीकृत होगा।" ऐसे "कार्यान्वयन-विशिष्ट और निजी-उपयोग" शीर्ष लेखों के लिए, RFC का कहना है कि एक विक्रेता जैसे कि उपसर्ग का नाम उचित है।

— एडवर्ड ब्रे
स्रोत

6

"RFC6648 अनुशंसा करता है कि आप मानते हैं कि आपका कस्टम हेडर" मानकीकृत, सार्वजनिक, आम तौर पर तैनात, या कई कार्यान्वयनों में प्रयोग करने योग्य हो सकता है। "मुझे लगता है कि यह X-उपसर्ग का उपयोग करने का एक कारण देता है क्योंकि यह किसी भी उपसर्ग के बिना होने की संभावना अधिक है, क्योंकि

— कोनराड

@Konrad यदि आप मान लेते हैं कि किसी और के समान हेडर (आपके हेडर नहीं) मानकीकृत हो सकते हैं, तो आप इसके साथ संघर्ष से बच सकते हैं X-, लेकिन यह मुख्य रूप से RFC6648 की तुलना में एक अलग धारणा है। भविष्य के मानक हेडर और किसी अन्य विक्रेता से हेडर के बीच संभावित संघर्ष के लिए RFC का अपवाद खाता है, जिसकी तकनीक कंपनी के विलय के माध्यम से आपके साथ एकीकृत हो सकती है, आदि यही कारण है कि अपवाद एक विक्रेता उपसर्ग के लिए कहता है।

— एडवर्ड ब्रे

17

यदि कुछ और नहीं तो अतिरिक्त HTTP हेडर को संशोधित या अधिक सही ढंग से जोड़ना एक बढ़िया कोड डीबगिंग टूल है।

जब एक URL अनुरोध एक अप्रत्यक्ष या एक छवि देता है तो डिबग कोड के परिणामों को अस्थायी रूप से लिखने के लिए कोई HTML "पृष्ठ" नहीं है - कम से कम एक ब्राउज़र में दिखाई देने वाला नहीं।

एक दृष्टिकोण यह है कि डेटा को स्थानीय लॉग फ़ाइल में लिखें और बाद में उस फ़ाइल को देखें। एक और अस्थायी रूप से HTTP हेडर को जोड़ने के लिए है जिसमें डेटा और चर को डीबग किया जा रहा है।

मैं नियमित रूप से अतिरिक्त HTTP हेडर जैसे एक्स-फ़ुबर-कोईवर: या एक्स-परीक्षण-सोमरसॉल्ट: को जोड़ देता हूं: चीजों को परखने के लिए - और बहुत सारे बग ढूंढ लिए हैं जो अन्यथा ट्रेस करना बहुत मुश्किल होता।

— g1smd
स्रोत

2

उसे इस "मानक" का उपयोग क्यों करना चाहिए? हेडर वही काम करते हैं। यहां तक कि "WHO_EVER_READS_THIS_IS_DUMB_" उपसर्ग के साथ ...

— अविश्वसनीय जन

16

शीर्षक फ़ील्ड नाम रजिस्ट्री RFC3864 में परिभाषित की गई है , और "X-" के साथ कुछ खास नहीं है।

जहां तक मैं बता सकता हूं, निजी हेडर के लिए कोई दिशानिर्देश नहीं हैं; संदेह में, उनसे बचें। या HTTP एक्सटेंशन फ्रेमवर्क ( RFC 2774 ) पर एक नज़र है ।

उपयोग के मामले को अधिक समझना दिलचस्प होगा; संदेश बॉडी में जानकारी क्यों नहीं जोड़ी जा सकती है?

— जूलियन रेज़्के
स्रोत

13

मुख्य कारण मैं कुछ कस्टम हेडर पर विचार कर रहा हूं ताकि मैं शरीर को पार्स करने के बिना रूटिंग निर्णय ले

— सकूं