कस्टम HTTP शीर्षलेख: नामकरण सम्मेलन




http-headers (4)

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

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


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

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

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


HTTP शीर्षकों के लिए प्रारूप HTTP विनिर्देश में परिभाषित किया गया है। मैं HTTP 1.1 के बारे में बात करने जा रहा हूं, जिसके लिए विनिर्देश आरएफसी 2616 है । सेक्शन 4.2 में, 'हेडर हेडर', हेडर की सामान्य संरचना को परिभाषित किया गया है:

   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>

जहां एलडब्ल्यूएस रैखिक सफेद स्थान है, जिसका परिभाषा मैं पुन: पेश नहीं करूंगा, और ओसीटीईटी है:

   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 वर्णों के उप-समूह से बना होना चाहिए - अल्फान्यूमेरिक्स, कुछ विराम चिह्न, बहुत कुछ नहीं। दूसरा, हेडर वैल्यू की परिभाषा में कुछ भी नहीं है जो इसे एएससीआईआई में प्रतिबंधित करता है या 8-बिट वर्णों को छोड़ देता है: यह स्पष्ट रूप से ऑक्टेट्स से बना है, केवल नियंत्रण वर्णों को प्रतिबंधित किया गया है (ध्यान दें कि सीआर और एलएफ नियंत्रण माना जाता है)। इसके अलावा, टेक्स्ट उत्पादन पर टिप्पणी का तात्पर्य है कि ऑक्टेट्स को आईएसओ -885 9 -1 में होने के रूप में व्याख्या किया जाना चाहिए, और यह कि एन्कोडिंग के बाहर वर्णों का प्रतिनिधित्व करने के लिए एक एन्कोडिंग तंत्र (जो भयानक, आकस्मिक रूप से) है।

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

उस ने कहा, मैं सभी सर्वरों, प्रॉक्सी और ग्राहकों में काम कर रहे आईएसओ -885 9 -1 पर भरोसा नहीं करता, इसलिए मैं रक्षात्मक प्रोग्रामिंग के मामले में एएससीआईआई के साथ रहूंगा।


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

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

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

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

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

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


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

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

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

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





http-headers