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




http-headers (4)

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

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


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 पर भरोसा नहीं करता, इसलिए मैं रक्षात्मक प्रोग्रामिंग के मामले में एएससीआईआई के साथ रहूंगा।


जून 2012 को, "एक्स-" उपसर्ग का उपयोग करने की सिफारिश का बहिष्कार आरएफसी 6648 के रूप में आधिकारिक बन गया है। प्रासंगिकता के उद्धरण नीचे दिए गए हैं:

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

...

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

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

...

  1. पंजीकृत होने से "एक्स-" उपसर्ग या समान संरचनाओं के साथ पैरामीटर को प्रतिबंधित नहीं करना चाहिए।

  2. यह निर्धारित नहीं करना चाहिए कि "एक्स-" उपसर्ग या समान संरचनाओं वाले पैरामीटर को गैर-मानकीकृत के रूप में समझा जाना चाहिए।

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

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

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

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


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

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

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


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

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

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

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





http-headers