असल में, ऐसा इसलिए होता है क्योंकि वेबसाइट ब्राउज़र को ऐसा करने के लिए कहती है। कभी-कभी, ऐसा इसलिए होता है क्योंकि वेबसाइट डेवलपर यह निर्णय लेते हैं कि वे इस व्यवहार को चाहते हैं, जैसे फ़ाइल साझा करने की साइट पर आम। अन्य बार, ऐसा इसलिए है क्योंकि यह जो भी सॉफ़्टवेयर उपयोग कर रहे हैं उनके लिए एक डिफ़ॉल्ट विकल्प है (उदाहरण के लिए फ़ोरम या ब्लॉगिंग सॉफ़्टवेयर)। कभी-कभी ऐसा होता है क्योंकि साइट देव को पता नहीं है कि वे क्या कर रहे हैं।
Content-Disposition
ऐसा इसलिए है क्योंकि साइट Content-Dispositionप्रतिक्रिया में हेडर भेजती है । विशेष रूप से, यह inlineया तो भेज सकता है या attachment।
inline डिफ़ॉल्ट है यदि अन्यथा निर्दिष्ट नहीं है, और इसका अर्थ है कि ब्राउज़र ब्राउज़र विंडो के भीतर फ़ाइल को खोल देगा यदि यह करने में सक्षम है।
attachment फ़ाइल को हमेशा डाउनलोड करने का मतलब है, इसे ब्राउज़र के अंदर खोलने का प्रयास न करें।
यदि आप अपने ब्राउज़र के डेवलपर टूल खोलते हैं, तो आप देखेंगे कि विशेष लिंक निम्नलिखित प्रतिक्रिया हेडर भेजता है:
Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf
यह ब्राउज़र को फ़ाइल को हमेशा डाउनलोड ( attachment) करने के लिए कहता है , और Schubert-Sonata-21-B-flat.pdfइसे URL से संदर्भित करने के बजाय इसे डिफ़ॉल्ट फ़ाइल नाम देने के लिए। इसके अतिरिक्त, यह ब्राउज़र (सही ढंग से) को बताता है कि यह एक application/pdfफ़ाइल है - लेकिन चूंकि यह एक attachmentब्राउज़र है फिर भी डाउनलोड करने के लिए डिफ़ॉल्ट होगा।
इनलाइन हैंडलिंग विवरण
जब एक Content-Dispositionइनलाइन (या अनिर्दिष्ट) है, तो ब्राउज़र डिफ़ॉल्ट रूप से एम्बेडेड दर्शक में फ़ाइल को खोलने का प्रयास करेगा। यह केवल तभी काम करता है जब ब्राउज़र जानता है कि यह किस प्रकार की फ़ाइल है, और ब्राउज़र जानता है कि उस प्रकार को कैसे खोलें।
प्रकार का पता लगाना
फ़ाइल प्रकार को Content-Typeहेडर के साथ सर्वर द्वारा निर्दिष्ट किया जा सकता है । उदाहरण के लिए, सबसे आम इनलाइन प्रकार हैं text/html, application/javascriptऔर text/css, एक आधुनिक वेबसाइट के तीन प्रमुख भागों को बनाना। आपके पास अधिक गूढ़ प्रकार भी हो सकते हैं application/pdf।
एक और संभावना है कि सर्वर ने एक निर्दिष्ट किया Content-Typeहै application/octet-stream। यह सबसे सामान्य प्रकार है, और यह ब्राउज़र को बताता है कि फ़ाइल सिर्फ मनमाना डेटा है - जिस बिंदु पर ब्राउज़र केवल एक चीज कर सकता है वह इसे डाउनलोड कर सकता है (सिद्धांत रूप में - हम उस पर पहुंच जाएंगे)।
जब Content-Typeसर्वर द्वारा निर्दिष्ट नहीं किया जाता है (और कभी-कभी तब भी जब यह होता है), ब्राउज़र वह प्रदर्शन कर सकता है जिसे फ़ाइल को पढ़ने और पैटर्न की तलाश करके प्रकार का अनुमान लगाने के लिए सूँघने के रूप में जाना जाता है ।
टाइपिंग हैंडल
किसी inlineअनिर्दिष्ट विवाद के साथ एक फ़ाइल प्राप्त करने पर , ब्राउज़र को यदि संभव हो तो ब्राउज़र के भीतर इसे खोलने की कोशिश करने की आवश्यकता है। ऐसा करने के लिए, यह फ़ाइल प्रकार को देखता है, और यदि यह उस प्रकार को पहचानता है जो इसे खोलने का प्रयास करेगा। अधिकांश ब्राउज़र text/एक साधारण टेक्स्ट दर्शक में किसी भी प्रकार को खोलेंगे , text/htmlएक वेबपेज के रूप में प्रस्तुत करने का प्रयास करेंगे, एक विशेष वाक्यविन्यास-हाइलाइट किए गए दर्शक आदि में खोलapplication/json सकते हैं ।
प्रकार application/octet-streamविशेष रूप से नियंत्रित किया गया था। चूंकि यह सबसे सामान्य प्रकार माना जाता है, बाइट्स की मनमानी धारा को दर्शाते हुए, कोई भी ऐसा हैंडलर नहीं माना जाता है जो इस "प्रकार" की सभी फाइलों पर लागू हो सके। उदाहरण के लिए, Firefox में, यह डिफ़ॉल्ट हैंडलर सेट करने में असमर्थता के रूप में प्रकट करने के लिए application/octet-stream।
कुछ वेबसाइटों ने भी गैर-मानक प्रकारों का उपयोग किया है। मैंने application/force-downloadउपयोग किया हुआ देखा है - जो एक डाउनलोड के रूप में समाप्त होता है क्योंकि ब्राउज़र पहचानता नहीं है या जानता है कि टाइप के साथ क्या करना है, लेकिन विशेष हैंडलिंग का आनंद नहीं application/octet-streamलेता है।
थोड़ा सा इतिहास का पाठ
यह देखने के लिए कि PDF को कैसे संभाला जाता है, हम वेब इतिहास में थोड़ा बदलाव कर सकते हैं। देखें, अतीत में, ब्राउज़र को पता नहीं था कि पीडीएफ क्या है। इसलिए वे इसे नहीं खोल सके। लेकिन हमने देखा है कि बिल्ट-इन पीडीएफ दर्शकों से बहुत पहले ही ब्राउज़र में पीडीएफ खोले जा रहे थे, इसलिए यह काम कैसे हुआ?
यह इन दिनों सीमित एक्सटेंशन / एडऑन्स के साथ क्या कर सकता है की तुलना में कहीं अधिक नियंत्रण के साथ ब्राउज़र कार्यक्षमता का विस्तार करना संभव हुआ करता था। उन सबसे उदारता से प्लगइन्स के रूप में जाना जाता था । इंटरनेट एक्सप्लोरर में, वे ActiveX नियंत्रण थे; मोज़िला फ़ायरफ़ॉक्स और बाद में Google क्रोम वे एनपीएपीआई प्लगइन्स थे। ये प्लगइन्स किसी भी अन्य प्रोग्राम को करने में सब कुछ करने में सक्षम थे, और इसके अलावा एक विशिष्ट फ़ाइल प्रकार के लिए खुद को एक हैंडलर के रूप में पंजीकृत कर सकते थे जो कि ब्राउज़र द्वारा अन्यथा पहचाना नहीं जा सकता है। (संयोग से, यह बाद में एक बड़ा सुरक्षा जोखिम पाया गया और इन शक्तिशाली प्लगइन्स के लिए समर्थन धीरे-धीरे गिरा दिया गया ...)
प्लगइन्स के दिनों में, आप Adobe Acrobat Reader को स्थापित करेंगे, जो तब ActiveX या NPAPI प्लगइन स्थापित करेगा जो application/pdfMIME प्रकार को पंजीकृत करेगा और ब्राउज़र को प्लगइन का उपयोग करके उन प्रकार के इनलाइन को खोलने के लिए कहेगा।
बेशक, इन प्लगइन्स के कारण कई सुरक्षा और प्रदर्शन समस्याओं के बाद, प्रमुख ब्राउज़र विक्रेताओं ने अधिकांश प्लगइन्स के लिए समर्थन को चरणबद्ध करते हुए अपने स्वयं के पीडीएफ दर्शकों को शामिल करने का फैसला किया। केवल एक ही हम अभी भी देख रहे हैं Adobe Shockwave Flash, जो संभालता है application/x-shockwave-flash।
इसके लिए वास्तव में अभी भी कुछ बचे हुए नियंत्रण हैं, उदाहरण के लिए फ़ायरफ़ॉक्स में Preview in Firefoxविकल्प अभी भी मौजूद है:
अतीत में, यह कई प्लगइन्स के बीच विकल्प की अनुमति देता था जो उस प्रकार को पंजीकृत करता था। उदाहरण के लिए, फ्लैश के लिए पंजीकृत प्रकारों की सूची:
उन दिनों HTML5 के साथ आए मीडिया समर्थन के बहुत पहले भी थे। यह सिर्फ PDF नहीं था - आपके ब्राउज़र को पता नहीं होगा कि MP4 कंटेनर या H.264 वीडियो को कैसे संभालना है, कोई विचार नहीं है कि एमपी 3 फ़ाइल आदि को कैसे चलाना है, आदि .. आपको VLC जैसे मीडिया प्लेयर द्वारा प्रदान किए गए प्लगइन्स दिखाई देंगे। या यहां तक कि विंडोज मीडिया प्लेयर, या वेबसाइटें फ्लैश में निर्मित मीडिया प्लेयर को एम्बेड करेंगी।
Content-Type: application/octet-streamलेकिन यह इन दिनों बहुत कम आम है।