2012-05-24 11 views
17

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

क्या कोई श्वेत पत्र, व्यापार लेख, असफल प्रयोग, या अन्य सबूत हैं कि क्यों न तो ब्राउज़र निर्माता या वेब-प्रदर्शन प्रचारक इस लंबे समय तक HTTP का भुगतान कर रहे हैं?

पूरी तरह स्पष्ट होने के लिए, मैं एक राय नहीं ढूंढ रहा हूं, लेकिन वास्तविक सबूत बताते हैं कि यह क्यों हो सकता है। उदाहरण के लिए, यदि मोज़िला ने कुछ साल पहले इस बारे में कुछ प्रकाशित किया था, या फ़ायरफ़ॉक्स बग ट्रैकर में एक बंद टिकट है जहां एक लीड डेवलपर टिप्पणी करता है कि वे इसे क्यों लागू नहीं करेंगे।

उत्तर

4

आईई के असल में पुराने संस्करण मल्टीपार्ट एप्लिकेशन/ऑक्टेट-स्ट्रीम प्रतिक्रियाओं को संसाधित करेंगे और डाउनलोड ऑपरेशन के दौरान सभी फाइलों को सहेजेंगे, लेकिन इसे हाल ही में हटा दिया गया था (आईई 7 के रूप में, मुझे लगता है) और केवल डाउनलोड करने के लिए विशिष्ट था।

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

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

निश्चित रूप से विभिन्न समाधानों की कल्पना करना आसान है, लेकिन मानक के बिना, यह ब्राउज़र डेवलपर्स के हिस्से पर प्रयास की गारंटी नहीं देगा। मैं माइक्रोसॉफ्ट (व्यापक रूप से अपनाए गए सर्वर और ब्राउजर पर नियंत्रण के साथ) की कल्पना कर सकता हूं, लेकिन वे एक spec का आविष्कार करेंगे और लोग शिकायत करेंगे। जाहिरा तौर पर हम तय कर लिया है यह 10 साल इंतजार करना बेहतर है W3C के लिए कुछ पर सहमत ...

+0

जब मैं टिप्पणी की सराहना करते, यह वास्तव में सिर्फ अटकलें (आईई अतीत [जो, btw, क्रोम और सफारी इस उसी तरह अब संभाल] में इस से निपटने के बारे मुलायम भोजन को छोड़ कर)। – coreyward

+2

मुद्दा यह है कि जो लोग वेब ब्राउज़र लिखते हैं वे सिर्फ यह मानना ​​शुरू नहीं कर रहे हैं कि एक मल्टीपार्ट प्रतिक्रिया किसी भी तरह से उस चीज़ को मैप करना चाहिए जो वे अंततः चाहते हैं। ऐसा नहीं है कि HTTP कैसे काम करता है, लेकिन यह प्रभावी रूप से आप जो प्रस्तावित कर रहे हैं वह प्रभावी है। – McGuireV10

+0

यह भी देखें https://bugzilla.mozilla.org/show_bug.cgi?id=843508 – Aldian

2

डब्ल्यू 3 ऑर्ग ही (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2 पर) से सीधे:

3.7.2 मल्टीपार्ट प्रकार

एमआईएम कई "मल्टीपार्ट" प्रकारों के लिए प्रदान करता है - के एक या अधिक इकाइयों को एक संदेश संदेश के भीतर encapsulations। सभी मल्टीपार्ट प्रकार आरएफसी 2046

[40] की धारा 5.1.1 में परिभाषित एक सामान्य वाक्यविन्यास साझा करते हैं, और मीडिया प्रकार मान के हिस्से के रूप में सीमा पैरामीटर शामिल करना आवश्यक है।संदेश निकाय स्वयं प्रोटोकॉल तत्व है और इसलिए शरीर के हिस्सों के बीच लाइन ब्रेक का प्रतिनिधित्व करने के लिए केवल सीआरएलएफ का उपयोग करें। आरएफसी 2046 के विपरीत, किसी भी मल्टीपार्ट संदेश का उपक्रम खाली होना चाहिए; HTTP अनुप्रयोगों को epilogue संचारित नहीं करना चाहिए (भले ही मूल मल्टीपार्ट में एक epilogue शामिल है)। यह प्रतिबंध में मौजूद हैं जो एक मल्टीपार्ट संदेश- शरीर की स्वयं-संकीर्ण प्रकृति को संरक्षित रखने के क्रम में हैं, जिसमें संदेश-शरीर का "अंत" मल्टीपार्ट सीमा समाप्त होता है।

सामान्य रूप से, HTTP से किसी भी अन्य मीडिया प्रकार से भिन्न नहीं है: सख्ती से पेलोड के रूप में। एक अपवाद "मल्टीपार्ट/बार्टेन्जेस" प्रकार (परिशिष्ट 1 9 .2) है जब यह 206 (आंशिक सामग्री) प्रतिक्रिया में प्रकट होता है, जिसका अर्थ कुछ HTTP कैशिंग तंत्र से खंडित किया जाएगा जैसा खंड 13.5.4 और 14.16 में वर्णित है। सभी अन्य मामलों में, एक HTTP उपयोगकर्ता एजेंट को समान या समान व्यवहार का पालन करना चाहिए क्योंकि एक एमआईएमई उपयोगकर्ता एजेंट मल्टीपार्ट प्रकार की प्राप्ति के बाद होगा। प्रत्येक शरीर के भीतर MIME शीर्षलेख फ़ील्ड- एक मल्टीपार्ट संदेश का हिस्सा- शरीर के पास MIME semantics द्वारा परिभाषित HTTP से कोई महत्व नहीं है।

सामान्य रूप से, एक HTTP उपयोगकर्ता एजेंट को एक समान या समान व्यवहार का पालन करना चाहिए क्योंकि एक एमआईएमई उपयोगकर्ता एजेंट मल्टीपार्ट प्रकार की प्राप्ति के बाद होगा। यदि किसी एप्लिकेशन को एक अपरिचित मल्टीपार्ट उप प्रकार प्राप्त होता है, तो एप्लिकेशन को इसे "मल्टीपार्ट/मिश्रित" के बराबर माना जाना चाहिए।

Note: The "multipart/form-data" type has been specifically defined 
    for carrying form data suitable for processing via the POST 
    request method, as described in RFC 1867 [15]. 
+2

यह मल्टीपार्ट प्रतिक्रियाओं का उपयोग करने पर कोई प्रतिबंध इंगित नहीं करता है। – coreyward

+0

मैंने इसके साथ जवाब दिया क्योंकि मैं हाल ही में एमआईएमई एक्सएचआर अनुरोधों और प्रतिक्रियाओं के साथ काम कर रहा हूं। मुझे लगता है कि मेरा जवाब वास्तव में यह कहने के अलावा आपके प्रश्न को संबोधित नहीं करता है कि यह निश्चित रूप से मानक का हिस्सा है और ऐसा कोई कारण नहीं है कि ब्राउज़र और सर्वर प्रोटोकॉल के इस हिस्से का समर्थन और सम्मान नहीं कर रहे हैं। – Phelonius

+0

मेरे लिए, मुझे एमआईएम अनुरोधों और प्रतिक्रियाओं को समझने और सही तरीके से संभालने के लिए उपयोग किए जा रहे किसी भी ब्राउज़र (एफएफ, क्रोम/क्रोमियम, ओपेरा, आईई) को प्राप्त करने में कोई समस्या नहीं है। – Phelonius

संबंधित मुद्दे