2009-09-11 6 views
8

मैं कुछ विरासत कोड की समीक्षा कर रहा हूं और मुझे एक बग मिली है जो प्रतिक्रिया को अनिश्चित काल तक बैठने का कारण बनती है।क्या मेरे प्रतिक्रिया शीर्षलेख में सामग्री-लंबाई सेट करना आवश्यक है?

यहाँ मूल विचार है:

Response.Content-Type = "application/octet-stream" 
Response.AddHeader("Content-Disposition", "attachment; filename" & someFileName) 
Response.AddHeader("Content-Length", someStoredLength) 
Response.BinaryWrite(someByteArray) 
Response.Flush() 
Response.End() 

समस्या यह है कि someStoredLength someByteArray के वास्तविक आकार से काफी अधिक है, इसलिए ग्राहक सिर्फ जबकि ब्राउज़र सिर्फ spins फ़ाइल डाउनलोड के लिए इंतज़ार कर वहाँ बैठता है।

मैं केवल AddHeader को हटाने का विचार कर रहा हूं जो सामग्री की लंबाई निर्दिष्ट करता है, क्योंकि जब मैं ऐसा करता हूं तो सबकुछ ठीक काम करता प्रतीत होता है, लेकिन मुझे चिंता है कि मैं कुछ समझ नहीं रहा हूं।

क्या यह मेरे लिए इस एडहेडर को हटाने के लिए ठीक है या क्या मुझे इस समस्या से निपटने के लिए एक बेहतर तरीका पता होना चाहिए?

+0

कौन-सी भाषा है? उपरोक्त कोड में प्रतिक्रिया वस्तु क्या कक्षा है? – noctonura

+0

@RichAmberale: यह वास्तव में प्रश्न के लिए प्रासंगिक नहीं है। HTTP हेडर के कारण ब्राउज़र पर समस्या होती है। –

+0

कोड वीबीएनईटी में है लेकिन मुझे यह अन्य स्थानों में मिल सकता है जहां विरासत एएसपी क्लासिक – Joseph

उत्तर

8

बदलें निम्न के सामग्री-लंबाई लाइन:

Response.AddHeader("Content-Length", someByteArray.Length.ToString()) 
+0

मैं भी ऐसा करने के बारे में सोच रहा था। मैं सोच रहा था कि क्या यह एक अच्छा विकल्प होगा। यदि मेरे पास बाइट सरणी है तो लंबाई की संपत्ति हमेशा मुझे सही आकार देगी? – Joseph

+0

हां। सामग्री-लंबाई शीर्षलेख सामग्री में बाइट्स की संख्या इंगित करता है। आपकी सामग्री बाइट्स की एक सरणी है, इसलिए आप अच्छे हैं। – Stephen

10

आपका आवेदन SHOULD (सामग्री-लंबाई तक नीचे स्क्रॉल करें) इसे परिभाषित करें, हालांकि, इसकी कड़ाई से आवश्यकता नहीं है।

यहां संभावित विकल्पों में से decent discussion है।

+2

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

+0

[सामग्री-लंबाई] के लिए सीधा लिंक (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13), यह भी देखें [HttpBis] (http://tools.ietf.org /html/draft-ietf-httpbis-p1-messaging-25#section-3.3.2) – paulkmoore