वीडियो और उपशीर्षक · डायरेक्ट मीडिया डाउनलोडर
रीडायरेक्ट, सामग्री-लंबाई और पहला बाइट: सीधे डाउनलोड का जीवन
· यह काम किस प्रकार करता है
http डाउनलोड डेवलपर-वर्कफ़्लो
डाउनलोड शुरू होने से लेकर पहली बाइट आने तक, कई HTTP चरण अदृश्य रूप से घटित होते हैं। यह पोस्ट रीडायरेक्ट, प्रतिक्रिया हेडर और कैसे फ़ेच उन्हें रिपोर्ट करता है, और उस टूल के लिए इसका क्या अर्थ है जो अपने होस्ट को सामने नाम देता है, समझाता है।
डाउनलोड शुरू हुआ और पाँच सेकंड तक कुछ नहीं हुआ - क्लिक और पहली बाइट के बीच के अदृश्य चरण
डाउनलोड दबाने के बाद पांच शांत सेकंड में कनेक्शन सेटअप, रीडायरेक्ट, सर्वर प्राधिकरण जांच और बॉडी चंक्स उपलब्ध होने से पहले प्रतिक्रिया हेडर की प्रतीक्षा करना शामिल हो सकता है। बाइट्स आने तक प्रगति पट्टी आगे नहीं बढ़ सकती है, इसलिए पहले अपडेट से पहले देरी स्वचालित रूप से एक जमे हुए इंटरफ़ेस नहीं है।
जब होस्ट क्रॉस-ऑरिजिन हेडर पढ़ने की अनुमति देता है तो वैकल्पिक चेक लिंक HEAD के माध्यम से स्थिति, सामग्री-प्रकार, सामग्री-लंबाई और बाइट-रेंज समर्थन को उजागर कर सकता है। यह एक अलग अनुरोध है, बाद में GET को तेज़ करने की गारंटी वाला वार्म-अप नहीं है, क्योंकि दोनों कॉल `cache: no-store` का उपयोग करते हैं। टाइमिंग ब्रेकडाउन के साथ एक ट्रेस, फील द्वारा प्रतीक्षा करने की तुलना में अधिक उपयोगी है क्योंकि यह कतार, कनेक्शन, सर्वर प्रतीक्षा और ब्राउज़र द्वारा उजागर किए गए बॉडी डाउनलोड चरणों को अलग करता है।
अनुरोध पंक्ति और हेडर: ब्राउज़र क्या भेजता है - विधि, पथ, स्वीकार करें, और एक क्रॉस-साइट फ़ेच डिफ़ॉल्ट रूप से क्या रोकता है
डाउनलोड मान्य HTTPS URL के विरुद्ध GET का उपयोग करता है। फ़ेच और ब्राउज़र वास्तविक अनुरोध शीर्षलेख बनाते हैं; एप्लिकेशन कोड स्पष्ट रूप से क्रेडेंशियल्स को छोड़ देता है और रेफरर को दबा देता है। यह उपयोगकर्ता-एजेंट या रेफरर को धोखा नहीं देता है, लॉगिन कुकीज़ संलग्न नहीं करता है, या प्लेटफ़ॉर्म टोकन नहीं जोड़ता है।
एक क्रॉस-साइट अनुरोध में अभी भी ब्राउज़र-नियंत्रित संदर्भ जैसे ओरिजिन शामिल हो सकता है। सटीक हेडर ब्राउज़र और वातावरण के अनुसार भिन्न होते हैं, इसलिए DevTools एक विशेष रन के लिए प्रमाण है। स्रोत कॉन्फ़िगर विधि, क्रेडेंशियल मोड, रेफ़रर नीति, कैश मोड, रीडायरेक्ट नीति और निरस्त सिग्नल को साबित करता है। HTTP प्रतिक्रियाओं में हेडर की उपस्थिति वैकल्पिक है और CORS स्क्रिप्ट दृश्यता को सीमित कर सकती है, इसलिए प्रदर्शित कुल की अनुपस्थिति एक खाली फ़ाइल का प्रमाण नहीं है।
रीडायरेक्ट: जब आपका नामित होस्ट आपको दूसरे को सौंपता है - कैसे 301, 302 और 307 प्रतिक्रियाओं का अनुसरण करता है और response.url अंतिम पता कैसे प्रकट करता है
HEAD और GET दोनों `redirect: follow` निर्दिष्ट करते हैं। इसलिए एक 301, 302, 307, या कोई अन्य समर्थित रीडायरेक्ट अनुरोध को घोषित प्रारंभिक URL से अंतिम संसाधन तक ले जा सकता है। फ़ेच केवल तभी हल होता है जब श्रृंखला किसी प्रतिक्रिया पर पहुंचती है या ब्राउज़र नीति के तहत विफल हो जाती है।
डाउनलोडर `response.url` प्रदर्शित नहीं करता है, भले ही फ़ेच प्रतिक्रिया अंतिम पता उजागर करती है। हॉप्स का ऑडिट करने के लिए, नेटवर्क लॉग को सुरक्षित रखें और वहां रीडायरेक्ट पंक्तियों का निरीक्षण करें। यह मायने रखता है क्योंकि पूर्व-संपर्क घोषणा में आपूर्ति किए गए होस्ट का नाम होता है; यह सर्वर द्वारा बाद में चुने गए स्थान की घोषणा नहीं कर सकता। 307-शैली संरक्षण के लिए विधि शब्दार्थ सामान्य पुनर्लेखन व्यवहार से भिन्न होता है, प्रत्येक हॉप को समान के रूप में सारांशित करने के बजाय ब्राउज़र ट्रेस पर भरोसा करने का एक और कारण।
सामग्री-लंबाई और सामग्री-प्रकार: प्रतिक्रिया शीर्षलेख क्या वादा करते हैं - मुख्य भाग समाप्त होने से पहले आकार और प्रकार कैसे ज्ञात होते हैं
सामग्री-प्रकार प्रतिक्रिया को लेबल करता है और ब्लॉब प्रकार बन जाता है, जबकि एक सकारात्मक परिमित सामग्री-लंबाई अपेक्षित कुल आपूर्ति करती है। GET पथ स्ट्रीमिंग से पहले 2 GiB से आगे घोषित कुल को अस्वीकार कर देता है। यदि हेडर गायब है, तो प्रगति अनिश्चित रहती है और वास्तविक प्राप्त बाइट्स गार्ड को लागू करते हैं।
हेडर सर्वर से प्राप्त कथन हैं, यह गारंटी नहीं देते कि मुख्य भाग अपने लेबल को पूरा करेगा या उससे मेल खाएगा। एक कनेक्शन जल्दी बंद हो सकता है, और एक एप्लिकेशन MIME मेटाडेटा को गलत तरीके से कॉन्फ़िगर कर सकता है। ToolAcre इन मानों का उपयोग विवरण, प्रगति और नामकरण निर्णयों के लिए करता है, बिना यह दावा किए कि वे मीडिया आंतरिक को मान्य करते हैं। कोड अधिकतम के विरुद्ध संचित बाइट्स की भी दोबारा जांच करता है, यह सुनिश्चित करते हुए कि अनुपस्थित या गलत लंबाई एप्लिकेशन की मेमोरी सीमा को अक्षम नहीं करती है।
कार्यान्वित उदाहरण: एक 'प्रत्यक्ष' लिंक जो एक लिंक शॉर्टनर के माध्यम से बाउंस करता है - नेटवर्क पैनल में प्रत्येक हॉप को पढ़ता है
संक्षिप्त अनुमत लिंक के लिए, DevTools खोलें, प्रिजर्व लॉग सक्षम करें, और चेक लिंक या डाउनलोड से प्रारंभ करें। उजागर होने पर इसकी रीडायरेक्ट स्थिति और स्थान देखने के लिए प्रारंभिक पंक्ति का विस्तार करें, फिर उस प्रतिक्रिया की श्रृंखला का अनुसरण करें जिसका मुख्य भाग फ़ाइल की आपूर्ति करता है। प्रत्येक होस्टनाम की अपेक्षित प्रकाशक संरचना से तुलना करें।
प्रथम-बाइट टाइमिंग कॉलम प्रतीक्षा को स्थानांतरण से अलग करता है। एक बार टुकड़े आ जाने पर, ToolAcre संचित बाइट्स की रिपोर्ट करता है; सामग्री-लंबाई के साथ यह एक अंश की गणना कर सकता है। देर से आने वाली पहली बाइट और उसके बाद तेज़ बॉडी, तत्काल प्रतिक्रिया से भिन्न बाधा और उसके बाद धीमी गति से निरंतर स्थानांतरण का सुझाव देती है। पुनर्प्रयासों के बीच तुलना में कैश सेटिंग्स और नेटवर्क स्थितियों को सुसंगत रखना चाहिए; अन्यथा परिवर्तित समय प्रोफ़ाइल मूल के बजाय परीक्षण सेटअप का वर्णन कर सकती है।
किसी घोषित होस्ट के लिए रीडायरेक्ट क्यों मायने रखता है - टूल आपके द्वारा दिए गए URL की घोषणा करता है; एक रीडायरेक्ट कहीं और ले जा सकता है, और नेटवर्क पैनल दिखाता है कि कहां
सबमिट किए गए होस्टनाम की घोषणा करना उपयोगी है लेकिन रीडायरेक्ट की अनुमति होने पर यह अनिवार्य रूप से अधूरा होता है। एक विश्वसनीय शॉर्टनर वैध रूप से स्टोरेज CDN पर इंगित कर सकता है, जबकि एक अप्रत्याशित श्रृंखला संगठनों को पार कर सकती है। इंटरफ़ेस उस श्रृंखला को पूर्व-समाधान नहीं करता है क्योंकि ऐसा करने के लिए स्वयं संपर्क की आवश्यकता होगी।
जिन समीक्षकों को अनुमति सूची की आवश्यकता होती है, उन्हें प्रत्येक देखे गए होस्टनाम को सत्यापित करना चाहिए या छोटे लिंक से पूरी तरह बचना चाहिए। ToolAcre सबमिट किए गए URL में स्पष्ट निजी गंतव्यों को ब्लॉक करता है, लेकिन यह एप्लिकेशन कोड में प्रत्येक रीडायरेक्ट लक्ष्य को पुनः मान्य करने का दावा नहीं करता है; ब्राउज़र नेटवर्क सुरक्षा एक और परत बनी हुई है। अंतिम CDN में शॉर्टनर से अलग गोपनीयता नीति और क्षेत्राधिकार हो सकता है, इसलिए गंतव्य समीक्षा सबमिट किए गए लिंक में दिखाई देने वाली ब्रांडिंग से आगे बढ़नी चाहिए।
इसमें क्या शामिल नहीं है - रेंज अनुरोध, फिर से शुरू करना, या सर्वर जो खंडित एन्कोडिंग और बिना लंबाई के स्ट्रीम करते हैं
यह वर्कफ़्लो रेंज अनुरोध नहीं भेजता है, बाधित बाइट्स को फिर से शुरू नहीं करता है, सामग्री-लंबाई को बाध्य नहीं करता है, या ज्ञात कुल के रूप में खंडित स्थानांतरण फ़्रेमिंग की पुन: व्याख्या नहीं करता है। HEAD `Accept-Ranges: bytes` की रिपोर्ट कर सकता है, फिर भी वर्तमान डाउनलोड अभी भी एक सामान्य GET निष्पादित करता है और शुरुआत से प्रतिक्रिया जमा करता है।
यह प्रमाणित भी नहीं करता. साइन-इन पेज पर रीडायरेक्ट HTML या HTTP इनकार उत्पन्न कर सकता है क्योंकि कुकीज़ हटा दी गई हैं। उस पेज को डाउनलोड करने योग्य मीडिया मानना गलत होगा, इसलिए पूर्व MIME चेतावनी और अंतिम प्रतिक्रिया हेडर का निरीक्षण उपयोगी सुरक्षा उपाय हैं। खंडित या प्रोटोकॉल-स्तरीय फ़्रेमिंग का उपयोग करने वाले सर्वर सामग्री-लंबाई के बिना पूर्ण बॉडी प्रदान कर सकते हैं, और UI सही ढंग से उस वैध अनिश्चितता को शून्य में बदलने से बचाता है।
टेकअवे: अपने हॉप्स को जानें - वास्तव में संपर्क किए गए प्रत्येक होस्ट को देखने के लिए डायरेक्ट मीडिया डाउनलोडर और नेटवर्क पैनल का एक साथ उपयोग कैसे करें
एक सीधा लिंक HTTP यात्रा की शुरुआत का वर्णन करता है, जरूरी नहीं कि यह एक भौतिक सर्वर हो। देखने योग्य अनुक्रम प्रारंभिक GET है, किसी भी अनुसरण किए गए रीडायरेक्ट, प्रतिक्रिया हेडर, पहला बॉडी हिस्सा, बाद का हिस्सा, ब्लॉब निर्माण और पूरा होने के बाद एक अलग स्थानीय सेव एक्शन।
जब गंतव्य उद्गम मायने रखता है तो डायरेक्ट मीडिया डाउनलोडर की प्रारंभिक-होस्ट घोषणा को नेटवर्क पैनल के साथ जोड़ें। वह संयोजन दिखाता है कि संपर्क से पहले क्या वादा किया गया था और बाद में वास्तव में क्या हुआ, फिर से शुरू करने योग्य स्थानांतरण, छिपी हुई प्रॉक्सी या रीडायरेक्ट भविष्यवाणी के लिए समर्थन का आविष्कार किए बिना। यह कालक्रम यह भी बताता है कि बचत पूरी होने के बाद ही क्यों दिखाई देती है: कार्यान्वयन आंशिक रूप से इकट्ठे ब्लॉब को उजागर नहीं करता है जैसे कि यह एक सत्यापित पूर्ण प्रतिक्रिया थी।