क्या डुप्लिकेट HTTP रिस्पांस हेडर स्वीकार्य हैं?

Question

मुझे इस बारे में कोई विनिर्देश नहीं मिला है कि डुप्लिकेट HTTP प्रतिक्रिया हेडर मानक द्वारा अनुमत हैं या नहीं, लेकिन मुझे यह जानने की आवश्यकता है कि क्या यह संगतता समस्याओं का कारण होगा।

कहो मेरे पास एक प्रतिक्रिया हैडर है:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Cache-Control: no-cache
Cache-Control: no-store
Location: http://localhost:9876/foo.bar
Content-Language: en-US
Content-Length: 0
Date: Mon, 06 Dec 2010 21:18:26 GMT

ध्यान दें कि Cache-Controlविभिन्न मूल्यों के साथ दो हेडर हैं। क्या ब्राउज़र हमेशा उनके साथ ऐसा व्यवहार करते हैं जैसे कि उन्हें "कैश-कंट्रोल: नो-कैश, नो-स्टोर" लिखा जाता है?

Answer 1

हाँ

यहाँ उपलब्ध HTTP RFC2616 कहते हैं:

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

तो, एक ही नाम वाले कई हेडर ठीक हैं (यदि संपूर्ण फ़ील्ड-वैल्यू को अल्पविराम से अलग की गई मान मानों के रूप में परिभाषित किया जाता है)

कैशे-नियंत्रण यहाँ प्रलेखित है: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 इस तरह:

Cache-Control   = "Cache-Control" ":" 1#cache-directive

#1cache-directiveवाक्य रचना कम से कम एक कैश-निर्देश तत्वों की सूची (यहाँ #values की औपचारिक परिभाषा के लिए देखें: परिभाषित करता है सांकेतिक कन्वेंशनों और जेनेरिक व्याकरण )

तो हाँ,

Cache-Control: no-cache, no-store

के बराबर है (आदेश महत्वपूर्ण है)

Cache-Control: no-cache
Cache-Control: no-store

Comments

आपकी त्वरित प्रतिक्रिया के लिए धन्यवाद, साइमन! लेकिन RFC 2616 से उद्धृत पैराग्राफ कैश-कंट्रोल पर भी लागू नहीं होता है? क्या मैं कुछ भूल रहा हूँ?

— सू झांग

लगभग 100% सही। कैश कंट्रोल कई मानों के लिए अनुमति देता है Cache-Control = "Cache-Control" ":" 1#cache-directive:। सूचना #से पहले cache-directive। यह इंगित करता है कि कई मान स्वीकार किए जाते हैं (ऊपर आपकी परिभाषा से सही) ...

— ircmaxell

"यदि और केवल अगर उस हेडर फ़ील्ड के लिए पूरे फ़ील्ड-मान को अल्पविराम से अलग की गई सूची के रूप में परिभाषित किया गया है" - तो मुझे लगता है कि कई मानों को अल्पविराम से अलग की गई सूची के रूप में परिभाषित किया जाना चाहिए, अर्थात, वे नहीं हो सकते अलग हेडर के रूप में विभाजित।

— एमपीएन

@mark - "यहाँ अल्पविराम से अलग की गई सूची" का अर्थ है "बीएनएफ व्याकरण में अल्पविराम से अलग सूची के रूप में परिभाषित"। कैश-कंट्रोल फ़ील्ड को वास्तव में उस तरह से परिभाषित किया गया है (x # blahblah)।

— साइमन मूरियर

नए RFC 7230 में कई हेडर को हैंडल करने की बात करने वाला सेक्शन है tools.ietf.org/html/rfc7230#section-3.2.2

— मैथ्यू बकेट

Answer 2

ध्यान दें कि HSTS RFC6797 RFC2616 का विरोध करता है (एसटीएस हेडर के कई उदाहरणों के लिए व्यवहार को परिभाषित करके "अगर और केवल अगर" भाषा का उल्लंघन करता है), हालांकि यह अल्पविराम से अलग किए गए मानों से आबाद नहीं है:

  "If a UA receives more than one STS header field in an HTTP
  response message over secure transport, then the UA MUST process
  only the first such header field."

Comments

गलत। RFC6797 एसटीएस हेडर को कॉमा से अलग की गई सूची के रूप में परिभाषित नहीं करता है। तो RFC 2616 से "if and only if" नियम बस एक ही लागू होता है (मतलब यह है कि कई STS हेडर की अनुमति नहीं है क्योंकि STS हेडर को अल्पविराम द्वारा अलग की गई सूची के रूप में परिभाषित नहीं किया गया है)। RFC6797 सिर्फ इसे गैर-निर्धारक बनाता है कि उस नियम का उल्लंघन करने के क्या परिणाम हैं, कुछ ऐसा जो RFC2616 को खुला छोड़ देता है।

— फ्रांसेस