2011-04-14 18 views
95

जहां तक ​​मैं समझ गया दो स्थानों पर जहां सामग्री प्रकार सेट करने के लिए देखते हैं:क्या मुझे http प्राप्त अनुरोधों के लिए सामग्री प्रकार की आवश्यकता है?

  1. ग्राहक शरीर वह सर्वर से भेज रहा है (पद के लिए उदाहरण के लिए)
  2. सर्वर सेट के लिए किसी सामग्री प्रकार सेट प्रतिक्रिया के लिए एक सामग्री प्रकार।

क्या इसका मतलब है कि मुझे अपने सभी अनुरोध (क्लाइंट साइड) के लिए सामग्री प्रकार सेट नहीं करना है या नहीं करना चाहिए। और अगर मैं कर सकता हूं या क्या सामग्री प्रकार होना चाहिए?

इसके अलावा मैंने कुछ पोस्टों में पढ़ा है कि क्लाइंट का सामग्री प्रकार निर्दिष्ट करता है कि क्लाइंट किस प्रकार की सामग्री प्राप्त करना चाहता है। तो शायद मेरा बिंदु 1 सही नहीं है? क्योंकि वे अनुरोध इकाई नहीं है

उत्तर

57
के अनुसार

RFC 7231 section 3.1.5.5:

प्रेषक संदेश एक पेलोड शरीर युक्त चाहिए कि संदेश जब तक की इरादा मीडिया प्रकार में एक Content-Type हैडर क्षेत्र उत्पन्न उत्पन्न करता है संलग्न प्रतिनिधित्व प्रेषक को अज्ञात है। यदि कोई सामग्री-प्रकार हेडर फ़ील्ड मौजूद नहीं है, तो प्राप्तकर्ता मई या तो मीडिया प्रकार "एप्लिकेशन/ऑक्टेट-स्ट्रीम" ([RFC2046], Section 4.5.1) मान सकता है या डेटा को अपने प्रकार का निर्धारण करने के लिए जांच सकता है।

इसका मतलब है कि Content-Type HTTP हेडर केवल PUT और POST अनुरोधों के लिए सेट किया जाना चाहिए।

+27

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

+2

@Epoc, उद्धृत संदेश सबसे अच्छा निहित है। यह ** वास्तव में ** नहीं कहता है कि बिना इकाई-शरीर के संदेशों को 'सामग्री नहीं' शामिल करना चाहिए। क्या हमारे पास एक स्पष्ट उद्धरण है? – Pacerier

+0

@Pacerier कृपया किसी और के जवाब के मूल निष्कर्ष को नकारें, भले ही यह गलत है। मैं मानता हूं कि एपोक का जवाब गलत है - उस खंड में कुछ भी नहीं जो उसने उद्धृत किया है, उसके जवाब के निष्कर्ष का समर्थन करता है, और इसे कम करने का हकदार है। लेकिन इसका मतलब यह नहीं है कि आपको अपने मूल आधार को खत्म करने के लिए जवाब संपादित करना चाहिए और इस प्रकार इसका अर्थ पूरी तरह से बदलना चाहिए। –

58

प्राप्त अनुरोधों सामग्री प्रकार होना नहीं होना चाहिए (यानी, एक शरीर है)

+18

@ डिमिट्री, ** उद्धरण वांछित **, अन्यथा यह एक तथ्य के रूप में नहीं, एक धारणा के रूप में खड़ा है। – Pacerier

+1

जबकि मैं मानता हूं कि spec यह नहीं कहता कि आपके पास GET पर सामग्री-प्रकार नहीं हो सकता है, नेट इसे अपने HttpClient में लागू करने के लिए प्रतीत होता है। Https://stackoverflow.com/questions/10679214/how-do-you-set-the-content-type-header-for-an-httpclient-request – Adam

25

प्राप्त अनुरोध हेडर, जो कहते हैं कि जो प्रकार की सामग्री की ग्राहक समझता है "स्वीकार" हो सकता है। सर्वर तब उपयोग कर सकता है यह तय करने के लिए कि किस सामग्री प्रकार को वापस भेजना है।

हालांकि वे वैकल्पिक हैं।

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

12

स्वीकृत उत्तर गलत है। उद्धरण सही है, दावा है कि PUT और POST में यह गलत होना चाहिए। ऐसी कोई आवश्यकता नहीं है कि PUT या POST में वास्तव में अतिरिक्त सामग्री हो। वास्तव में सामग्री प्राप्त करने के खिलाफ कोई प्रतिबंध नहीं है।

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