HTTP रेंज हेडर

Question

मैं http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 पढ़ रहा था और फ़ाइल डाउनलोड जारी रखने का तरीका जानने का प्रयास कर रहा था।

उदाहरण के लिए, मान लीजिए कि फ़ाइल लंबाई 100 बाइट्स है और मेरे पास सभी 100 बाइट हैं। हालांकि, मैं क्या उम्मीद फ़ाइल आकार होना चाहिए पता नहीं है, इसलिए मैं फ़ाइल के लिए पूछने के लिए और एक रेंज हैडर कि इस तरह दिखता है निर्दिष्ट करें:

Range: bytes=100- 

यह एक वैध रेंज अनुरोध है?

Answer 1

यह एक वाक्य रचनात्मक रूप से मान्य अनुरोध है, लेकिन एक संतोषजनक अनुरोध नहीं है। यदि आप उस अनुभाग में आगे देखने के लिए आप देखते हैं:

अगर एक वाक्य रचना वैध बाइट-सीमा-सेट शामिल है कम से कम एक byte- रेंज-कल्पना जिनकी पहली बाइट-स्थिति entity- की वर्तमान लंबाई से भी कम है शरीर, या कम से कम एक प्रत्यय-बाइट-रेंज-स्पेक गैर-शून्य प्रत्यय-लंबाई के साथ, तब बाइट-रेंज-सेट संतोषजनक है। अन्यथा, बाइट-रेंज-सेट असंतुष्ट है। यदि बाइट-रेंज-सेट असंतुष्ट है, तो सर्वर को 416 की स्थिति (अनुरोधित सीमा संतोषजनक नहीं) की स्थिति के साथ प्रतिक्रिया वापस करनी चाहिए। अन्यथा, सर्वर को 206 (आंशिक सामग्री) की स्थिति के साथ प्रतिक्रिया वापस करनी चाहिए जिसमें इकाई-शरीर की संतोषजनक श्रेणियां हों।

तो मुझे लगता है कि आपके उदाहरण में, सर्वर को 416 वापस करना चाहिए क्योंकि यह उस फ़ाइल के लिए वैध बाइट रेंज नहीं है।

Answer 2

Wrikken सुझाव दिया गया है, यह एक वैध अनुरोध है। यह भी काफी आम है जब ग्राहक मीडिया का अनुरोध कर रहा है या डाउनलोड फिर से शुरू कर रहा है।

एक क्लाइंट अक्सर यह देखने के लिए परीक्षण करेगा कि सर्वर Accept-Ranges प्रतिक्रिया की तलाश के अलावा अन्य अनुरोधों को संभालता है या नहीं। क्रोम हमेशा एक वीडियो के लिए अपने पहले जीईटी अनुरोध के साथ Range: bytes=0- भेजता है, इसलिए ऐसा कुछ है जिसे आप बर्खास्त नहीं कर सकते हैं।

जब भी कोई ग्राहक Range: अपने अनुरोध में शामिल करता है, भले ही यह विकृत हो, तो यह आंशिक सामग्री (206) प्रतिक्रिया की अपेक्षा कर रहा है। जब आप एचटीएमएल 5 वीडियो प्लेबैक के दौरान आगे बढ़ते हैं, तो ब्राउज़र केवल शुरुआती बिंदु का अनुरोध करता है। उदाहरण के लिए:

Range: bytes=3744- 

तो, ग्राहक के लिए आदेश वीडियो ठीक से खेलने के लिए, अपने सर्वर इन अधूरा रेंज अनुरोधों को हैंडल करने में सक्षम होना चाहिए।

आप दो तरह से 'सीमा' के प्रकार आप अपने प्रश्न में निर्दिष्ट संभाल कर सकते हैं:

सबसे पहले, आप जवाब में दिए गए अनुरोध किया प्रारंभिक बिंदु के साथ उत्तर सकता है, तो फ़ाइल शून्य से एक की कुल लंबाई (अनुरोधित बाइट रेंज शून्य-अनुक्रमित है)। उदाहरण के लिए:

अनुरोध:

GET /BigBuckBunny_320x180.mp4 
Range: bytes=100- 

प्रतिक्रिया:

206 Partial Content 
Content-Type: video/mp4 
Content-Length: 64656927 
Accept-Ranges: bytes 
Content-Range: bytes 100-64656926/64656927 

दूसरे, आप अनुरोध और एक ओपन एंडेड फ़ाइल लंबाई (आकार) में दिए गए प्रारंभिक बिंदु के साथ उत्तर सकता है। यह वेबकास्ट या अन्य मीडिया के लिए है जहां कुल लंबाई अज्ञात है।उदाहरण के लिए:

अनुरोध:

GET /BigBuckBunny_320x180.mp4 
Range: bytes=100- 

प्रतिक्रिया:

206 Partial Content 
Content-Type: video/mp4 
Content-Length: 64656927 
Accept-Ranges: bytes 
Content-Range: bytes 100-64656926/* 

सुझाव:

तुम हमेशा रेंज के साथ शामिल सामग्री की लंबाई के साथ जवाब चाहिए।

अनुरोध:: रेंज: सीमा समाप्त करने के लिए शुरू के साथ पूरा, है, तो सामग्री की लंबाई बस फर्क है बाइट्स = 500-1000

प्रतिक्रिया: सामग्री-रेंज: बाइट्स 500-1000/123456

याद रखें कि सीमा शून्य अनुक्रमित है, इसलिए Range: bytes=0-999 वास्तव में 1000 बाइट्स, नहीं 999 अनुरोध कर रहा है, इसलिए की तरह कुछ के साथ जवाब:

Content-Length: 1000 
Content-Range: bytes 0-999/123456 

या:

Content-Length: 1000 
Content-Range: bytes 0-999/* 

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

X-Content-Duration: 63.23 

यह एक फ़्लोटिंग पॉइंट होना चाहिए। Content-Length के विपरीत, यह मान सटीक नहीं होना चाहिए। यह प्लेयर को वीडियो के चारों ओर खोजने में मदद करने के लिए प्रयोग किया जाता है। यदि आप वेबकास्ट स्ट्रीम कर रहे हैं और केवल एक सामान्य विचार है कि यह कब तक होगा, तो यह अनुमानित अवधि को पूरी तरह से अनदेखा करने के बजाय बेहतर है। तो, एक दो घंटे की वेबकास्ट के लिए, आप की तरह कुछ में शामिल हैं:

Content-Type: video/webm 

:

X-Content-Duration: 7200.00 

ऐसे webm के रूप में कुछ मीडिया प्रकार, के साथ

, आप भी इस तरह के रूप सामग्री प्रकार, शामिल करना चाहिए मीडिया के लिए विशेष रूप से एचटीएमएल 5 में खेलने के लिए ये सभी आवश्यक हैं। यदि आप कोई अवधि नहीं देते हैं, तो खिलाड़ी अपनी फ़ाइल आकार से अवधि (मांग करने की अनुमति देने) को समझने का प्रयास कर सकता है, लेकिन यह सटीक नहीं होगा। यह ठीक है, और वेबकास्ट या लाइव स्ट्रीमिंग के लिए जरूरी है, लेकिन वीडियो फ़ाइलों के प्लेबैक के लिए आदर्श नहीं है। आप FFMPEG जैसे सॉफ़्टवेयर का उपयोग करके अवधि निकाल सकते हैं और उसे डेटाबेस या यहां तक ​​कि फ़ाइल नाम में सहेज सकते हैं।

X-Content-DurationContent-Duration के पक्ष में चरणबद्ध हो रहा है, इसलिए मैं भी इसमें शामिल करूंगा। एक बुनियादी, एक "0-" अनुरोध के जवाब में कम से कम शामिल होगा निम्नलिखित:

HTTP/1.1 206 Partial Content 
Date: Sun, 08 May 2013 06:37:54 GMT 
Server: Apache/2.0.52 (Red Hat) 
Accept-Ranges: bytes 
Content-Length: 3980 
Content-Range: bytes 0-3979/3980 
Content-Type: video/webm 
X-Content-Duration: 2054.53 
Content-Duration: 2054.53 

एक और बिंदु: क्रोम हमेशा के साथ अपने पहले वीडियो अनुरोध शुरू होता है निम्नलिखित:

Range: bytes=0- 

कुछ सर्वर होगा एक उत्तर के रूप में एक नियमित 200 प्रतिक्रिया भेजें, जो इसे स्वीकार करता है (लेकिन सीमित प्लेबैक विकल्पों के साथ), लेकिन अपने सर्वर हैंडल रेंज की तुलना में दिखाने के लिए 206 भेजने का प्रयास करें। RFC 2616 का कहना है कि रेंज हेडर को अनदेखा करना स्वीकार्य है।

Answer 3

मार्क नोवाकोव्स्की उत्तर के विपरीत, जो किसी कारण से कई लोगों द्वारा उखाड़ फेंका गया है, हां, यह एक वैध और संतोषजनक अनुरोध है।

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