वीडियो और उपशीर्षक · YouTube थंबनेल डाउनलोडर और मेटाडेटा व्यूअर
एक ब्राउज़र क्रॉस-ओरिजिनल छवि को कैसे सहेजता है: फ़ेच, ब्लॉब URL और डाउनलोड
· यह काम किस प्रकार करता है
YouTube जावास्क्रिप्ट कोर
किसी अन्य डोमेन से किसी छवि को सहेजना डाउनलोड विशेषता वाले लिंक की तुलना में कठिन है। यह पोस्ट बताती है कि क्रॉस-ओरिजिनल URL के लिए विशेषता को क्यों नजरअंदाज किया जाता है, फ़ेच और ब्लॉब URL इसे कैसे हल करते हैं और CORS का इससे क्या लेना-देना है।
डाउनलोड विशेषता ने छवि को सहेजने के बजाय उसे खोल दिया - क्रॉस-ओरिजिनल कैच
किसी भिन्न मूल की ओर इंगित किया गया एंकर वांछित फ़ाइल नाम का सम्मान करने के बजाय किसी छवि पर नेविगेट कर सकता है। एक भरोसेमंद डाउनलोडर को ब्राउज़र क्रॉस-ओरिजिन नियमों के तहत पढ़ने योग्य बाइट्स की आवश्यकता होती है, न कि केवल रिमोट URL पर एक डाउनलोड विशेषता की। दृश्यमान परीक्षण सीधा है: सत्यापित JPEG को सहेजने से कोई अन्य i.ytimg.com अनुरोध जोड़े बिना ToolAcre फ़ाइल नाम बन जाना चाहिए।
ToolAcre पहले से ही प्रत्येक JPEG उम्मीदवार को यह निर्धारित करने के लिए लाता है कि क्या यह वास्तविक है। सफल ब्लॉब रखने का मतलब है कि बाद में डाउनलोड दूसरा नेटवर्क अनुरोध जारी करने के बजाय उन्हीं बाइट्स का उपयोग कर सकता है। वह पुन: उपयोग सहेजी गई फ़ाइल को उस छवि के समान रखता है जिसके आयाम और प्लेसहोल्डर स्थिति का कुछ समय पहले निरीक्षण किया गया था।
ब्राउज़र अन्य मूल के लिए डाउनलोड को अनदेखा क्यों करते हैं - एक सुरक्षा निर्णय और उसके परिणाम
ब्राउज़र क्रॉस-ओरिजिनल डाउनलोड को बाधित करते हैं क्योंकि किसी पेज को चुपचाप नाम बदलने और मनमाने दूरस्थ संसाधनों को सहेजने की अनुमति नहीं देनी चाहिए। व्यवहार दूरस्थ प्रतिक्रिया और मूल संबंध पर निर्भर करता है, इसलिए एक साधारण लिंक एक सार्वभौमिक फ़ाइल-सेविंग API नहीं है। अकेले `download` विशेषता यह गारंटी नहीं दे सकती कि एक दूरस्थ YouTube छवि अनुरोधित स्थानीय नाम के तहत सहेजी जाएगी।
सुरक्षित डिज़ाइन स्पष्ट है: एक प्रकट सार्वजनिक छवि का अनुरोध करें, प्रतिक्रिया को सत्यापित करें, और केवल उस डेटा के लिए ब्राउज़र-प्रबंधित ऑब्जेक्ट URL का निर्माण करें जिसे पेज को पढ़ने की अनुमति थी। यदि CORS पहुंच को अवरुद्ध करता है, तो JavaScript के पास सत्यापित करने या सहेजने के लिए कोई ब्लॉब नहीं है, भले ही छवि पते पर सीधे नेविगेट करना अभी भी इसे एक टैब में प्रदर्शित कर सकता है।
फ़ेच-एंड-ब्लॉब मार्ग - छवि बाइट्स लाना, उन्हें ब्लॉब में लपेटना और समान-मूल ब्लॉब बनाना: URL
JPEG के लिए, जांच थंबनेल एक अज्ञात CORS GET निष्पादित करता है, एक सफल प्रतिक्रिया को ब्लॉब में परिवर्तित करता है और आयामों को डीकोड करता है। परिणाम पर एक प्रयोग करने योग्य ब्लॉब बरकरार रखा जाता है, जबकि प्लेसहोल्डर्स को हटा दिया जाता है ताकि वे डाउनलोड के रूप में सामने न आ सकें। इसलिए डाउनलोड बटन मेमोरी में सत्यापित बाइट्स का प्रतिनिधित्व करता है, न कि केवल फ़ाइल नाम या HTTP 200 से अनुमानित आत्मविश्वास का।
एक ऑब्जेक्ट URL स्थानीय सेव एक्शन के लिए उस इन-मेमोरी ब्लॉब का प्रतिनिधित्व कर सकता है। यह मूल फ़ेच को स्थानीय नहीं बनाता है; Google ने Fetch के बाद सीधे ब्राउज़र को बाइट्स प्रदान कीं। `blob:` पता उस प्रतिक्रिया निकाय के लिए एक अस्थायी ब्राउज़र हैंडल है, न कि ToolAcre द्वारा होस्ट किया गया दर्पण या स्रोत छवि के लिए नया दिया गया अधिकार।
CORS JPEG फ़ेच-एंड-ब्लॉब डाउनलोड की अनुमति देता है; WebP केवल लिंक ही रहता है
उल्लिखित रूपरेखा CORS एक सामान्य गेट थी, लेकिन भेजा गया व्यवहार प्रारूप-विशिष्ट है। JPEG फ़ेच-एंड-ब्लॉब डाउनलोड कार्य करता है; /vi_webp/ पथ आवश्यक क्रॉस-ओरिजिन हेडर के बिना परोसा जाता है, इसलिए ToolAcre WebP को केवल एक लिंक के रूप में प्रदान करता है। एक समीक्षक को प्रत्येक थंबनेल प्रारूप में JPEG प्रतिक्रिया शीर्षलेखों को सामान्यीकृत करने के बजाय दो पथ परिवारों का अलग-अलग परीक्षण करना चाहिए।
JavaScript को बदलने या ToolAcre के माध्यम से पुनः प्रयास करने से उस सीमा की मरम्मत नहीं की जा सकती, क्योंकि कोई ToolAcre प्रॉक्सी मौजूद नहीं है। एक अवरोधक, ऑफ़लाइन कनेक्शन या कॉर्पोरेट प्रॉक्सी भी दूरस्थ संसाधन को रोक सकता है। लिंक-ओनली WebP एक्सेस सटीक रूप से दर्शाता है कि रिमोट सर्वर पेज को क्या करने की अनुमति देता है: फ़ाइल को इंगित करें, लेकिन रीपैकेजिंग के लिए उसके बाइट्स को न पढ़ें।
सहेजी गई फ़ाइल का नामकरण - क्यों एक डाउनलोडर को इसे वीडियो ID और आकार के आधार पर नाम देना चाहिए ताकि फ़ाइलें पहचानी जा सकें
डाउनलोड किए गए JPEG नाम youtube-VIDEO_ID-VARIANT.jpg का उपयोग करते हैं। पहचानकर्ता और संस्करण दोनों मान्य वर्णमाला से आते हैं, जो पथ विभाजक या मनमाने ढंग से नियंत्रण वर्णों को सुझाए गए फ़ाइल नाम में प्रवेश करने से रोकते हैं। इसलिए एक लुकअप से `maxresdefault` और `hq2` को सहेजने से अलग, पूर्वानुमानित नाम उत्पन्न होने चाहिए जिनका उनकी परिणाम पंक्तियों से मिलान किया जा सके।
जब कई आकार एक फ़ोल्डर में बैठते हैं तो एक वर्णनात्मक फ़ाइल नाम उत्पत्ति को सुरक्षित रखता है। यह यह दिखावा करने से भी बचता है कि मेटाडेटा शीर्षक एक सुरक्षित फ़ाइल सिस्टम नाम है, क्योंकि शीर्षक में विराम चिह्न हो सकते हैं और स्वतंत्र रूप से बदल सकते हैं। अपरिवर्तनीय ID वीडियो संदर्भ की पहचान करती है, जबकि वैरिएंट प्रत्यय बताता है कि किस प्रकाशित छवि उम्मीदवार ने बाइट्स की आपूर्ति की है।
व्यावहारिक उदाहरण: एक वीडियो के लिए दो थंबनेल आकार सहेजना - अनुरोधों का क्रम और परिणामी फ़ाइलें
एक सार्वजनिक वीडियो प्राप्त करें और दो उपलब्ध JPEG प्रकार चुनें। जांच के दौरान प्रत्येक से एक बार अनुरोध किया गया, आयामों को साबित करने के लिए डिकोड किया गया और ब्लॉब के रूप में रखा गया; सेव पर क्लिक करने से उस परिणाम का पुन: उपयोग होना चाहिए और दो स्पष्ट रूप से नामित फ़ाइलें उत्पन्न होनी चाहिए। DevTools के खुले होने पर, दूसरी छवि अनुरोध की अनुपस्थिति यह पुष्टि करती है कि सेव ताज़ा रिमोट डाउनलोड के बजाय बरकरार रखी गई प्रतिक्रिया से आया है।
यदि कोई उम्मीदवार HTTP 200 को 120×90 प्लेसहोल्डर के रूप में लौटाता है, तो टूल इसे गायब चिह्नित करता है और कोई डाउनलोड करने योग्य ब्लॉब संग्रहीत नहीं करता है। एक 404, अन्य त्रुटि या अनडिकोडेबल प्रतिक्रिया भी सहेजे जाने के बजाय रिपोर्ट की जाती है। इन पंक्तियों के लिए सेव एक्शन को अक्षम करना एक सामान्य प्लेसहोल्डर या त्रुटि पेलोड को एक ठोस वैरिएंट नाम के तहत एसेट फ़ोल्डर में प्रवेश करने से रोकता है।
इसमें क्या शामिल नहीं है - कEVडियो में बैच डाउनलोड, और होस्ट जो क्रॉस-ओरिजिनल रीड को ब्लॉक करते हैं
कEVडियो में कोई बैच मोड नहीं है और होस्ट के लिए कोई बाईपास नहीं है जो क्रॉस-ओरिजिनल रीडिंग को प्रतिबंधित करता है। उत्पाद एक समय में एक वीडियो को संभालता है और खुद को दो प्रकट Google सेवाओं तक ही सीमित रखता है। प्रत्येक बरकरार ब्लॉब वर्तमान परिणाम सेट से संबंधित है, इसलिए इसे बाद के वीडियो या उसी थंबनेल के भविष्य के संस्करणों के लिए टिकाऊ कैश के रूप में नहीं माना जाना चाहिए।
यह वीडियो या ऑडियो को भी पुनर्प्राप्त नहीं करता है, और निजी, हटाए गए या आयु-प्रतिबंधित रिकॉर्ड अनुपलब्ध रहते हैं। एक सार्वजनिक फ़ाइल-बचत तंत्र पहुंच अधिकारों का विस्तार नहीं कर सकता है या अनुपस्थित थंबनेल का निर्माण नहीं कर सकता है। ब्लॉब निर्माण पठनीय छवि बाइट्स आने के बाद ही शुरू होता है, इसलिए यह अस्वीकृत प्रतिक्रिया या अप्रकाशित संस्करण के आसपास कोई मार्ग प्रदान नहीं करता है।
JPEG फ़ेच करें, ब्लॉब का पुन: उपयोग करें और डाउनलोड करें—WebP को एक लिंक के रूप में रखा गया है
फ़ेच से पहले, URL पार्सिंग स्थानीय है। बाद में, प्रत्येक JPEG जांच और कैनोनिकल oEmbed अनुरोध सीधे ब्राउज़र से चला जाता है जिसमें क्रेडेंशियल छोड़े जाते हैं, कोई रेफरर नहीं होता है, कोई स्टोर नहीं होता है और रीडायरेक्ट का पालन किया जाता है; Google ओरिजिन हेडर देखता है. दिनांक महत्वपूर्ण डाउनलोड स्वतंत्र रूप से, क्योंकि न तो ऑब्जेक्ट URL और न ही पूर्वानुमानित स्रोत पथ पहले के थंबनेल संशोधन को संरक्षित करता है।
परिणाम जानबूझकर असममित है: सत्यापित JPEG बाइट्स ब्लॉब डाउनलोड बन सकते हैं, जबकि पांच WebP पोस्टर URL बाहरी लिंक बने रहते हैं क्योंकि उनकी प्रतिक्रियाओं में CORS अनुमति का अभाव होता है। इंटरफ़ेस को उस ईमानदार सीमा को संरक्षित करना चाहिए। उपयोगकर्ता WebP पते को खोल या कॉपी कर सकते हैं, लेकिन ToolAcre बाइट्स से स्थानीय WebP फ़ाइल का नाम बदलने का वादा नहीं कर सकते, ब्राउज़र इसे पढ़ने से रोकता है।