2011-02-09 12 views
99

मैं nginx/ruby-on-rails चला रहा हूं और मेरे पास फ़ाइलों को अपलोड करने के लिए एक साधारण मल्टीपार्ट फ़ॉर्म है। सब कुछ ठीक काम करता है जब तक कि मैं अपलोड की गई फ़ाइलों के अधिकतम आकार को प्रतिबंधित करने का निर्णय नहीं लेता। ऐसा करने के लिए, मैंने nginx client_max_body_size से 1m (1MB) सेट किया है और उस नियम को तोड़ने पर प्रतिक्रिया में HTTP 413 (अनुरोध इकाई बहुत बड़ी) स्थिति की अपेक्षा है।nginx अपलोड client_max_body_size समस्या

समस्या कि जब मैं एक 1.2 एमबी फाइल अपलोड करें, बजाय HTTP 413 त्रुटि पृष्ठ प्रदर्शित करने में, ब्राउज़र एक सा लटका हुआ है और उसके बाद के साथ संदेश एक "यह पृष्ठ लोड किया गया था कनेक्शन रीसेट किया गया था" मर जाता है।

मैंने nginx ऑफ़र के बारे में हर विकल्प की कोशिश की है, कुछ भी काम नहीं करता है। क्या किसी के पास इस बारे में कोई विचार है?

worker_processes 1; 
timer_resolution 1000ms; 
events { 
    worker_connections 1024; 
} 

http { 
    passenger_root /the_passenger_root; 
    passenger_ruby /the_ruby; 

    include  mime.types; 
    default_type application/octet-stream; 

    sendfile   on; 
    keepalive_timeout 65; 

    server { 
     listen 80; 
     server_name www.x.com; 
     client_max_body_size 1M; 
     passenger_use_global_queue on; 
     root /the_root; 
     passenger_enabled on; 

     error_page 404 /404.html; 
     error_page 413 /413.html;  
    }  
} 

धन्यवाद:

यहाँ मेरी nginx.conf है।


**Edit**

पर्यावरण/यूए: Windows XP/फ़ायरफ़ॉक्स 3.6.13

उत्तर

109

nginx "तेजी से विफल रहता है" जब ग्राहक यह सूचित करता है कि यह 413 प्रतिक्रिया भेजकर और कनेक्शन बंद करके client_max_body_size से बड़ा शरीर भेजने जा रहा है।

अधिकतर ग्राहक पूरे अनुरोध निकाय को भेजे जाने तक प्रतिक्रियाएं नहीं पढ़ते हैं। चूंकि nginx कनेक्शन बंद कर देता है, क्लाइंट बंद सॉकेट पर डेटा भेजता है, जिससे टीसीपी आरएसटी होता है।

यदि आपका HTTP क्लाइंट इसका समर्थन करता है, तो इसे संभालने का सबसे अच्छा तरीका Expect: 100-Continue शीर्षलेख भेजना है। Nginx 1.2.7 के रूप में इसका सही ढंग से समर्थन करता है, और 100 Continue के बजाय 413 Request Entity Too Large प्रतिक्रिया के साथ उत्तर देगा यदि Content-Length अधिकतम शरीर आकार से अधिक है।

+1

ओह, मुझे यह इंगित करना चाहिए कि यह जवाब मानता है कि यह जवाब मानता है क्लाइंट 'ट्रांसफर-एन्कोडिंग: चंकड' करने के बजाए 'सामग्री-लंबाई' भेज रहा है। –

+2

nginx लेखक ने मेलिंग सूची पर इसे ठीक करने के लिए एक पैच पोस्ट किया: http://nginx.2469901.n2.nabble.com/client-max-body-size-and-100-Continue-413-Request-Entity-Too -Large-tp7582547p7582554.html कोई शब्द नहीं है कि इसे 1.2.x स्थिर शाखा में जोड़ा जाएगा या नहीं। –

+0

धन्यवाद, वास्तव में बहुत कुछ बताता है। निश्चित रूप से 'अपेक्षा' जैसा दिखता है बड़े अनुरोधों के लिए जाने का तरीका है। – krukid

7

the documentation से:

ऐसा नहीं है कि अन्य ब्राउज़रों को ध्यान में रखने के लिए आवश्यक है यह त्रुटि सही तरीके से दिखाने के बारे में नहीं पता।

मुझे लगता है यह क्या हो रहा है है, यदि आप करने के लिए यहाँ से वहाँ HTTP निरीक्षण उपकरण जैसे Firebug या Live HTTP Headers (दोनों Firefox एक्सटेंशन) के रूप में आप क्या वास्तव में हो रहा है देखने के लिए सक्षम हो जाएगा का उपयोग कर।

+1

मैं भी है कि यहाँ का सामना करना पड़ा,: http://forum.nginx.org/read.php?2,2620 कहाँ nginx लेखक का कहना है कि लोगों की कोशिश कर सकते बदलते lingering_time/lingering_timeout - इन दोनों का था मेरे मामले में कोई प्रभाव नहीं। इसके अलावा, मैं यह नहीं देखता कि एक स्थिर टाइमआउट समस्या कैसे हो सकती है जब मैं 1.2 एमबी फ़ाइल को 1 एमबी सीमा के साथ आसानी से स्थिर 5 एमबीपीएस कनेक्शन के साथ अपलोड कर रहा हूं। मैंने प्रतिक्रिया को झुका दिया है और यह 413 पृष्ठ को "कनेक्शन: क्लोज़" हेडर के साथ भेजता है, लेकिन कनेक्शन बंद नहीं लग रहा है। – krukid

+0

मुझे लगता है कि मुझे विश्वास करने में कठिनाई है कि भले ही पूरी तरह वैध 413 HTTP स्थिति है, यह ब्राउज़र में आग नहीं है। मैंने कई जगहों पर गुमराह किया है जहां लोग उस पृष्ठ से छुटकारा नहीं पा सकते हैं, और मैंने इसे कभी नहीं देखा। – krukid

+0

यदि आप यात्री अक्षम करते हैं, तो क्या यह कनेक्शन बंद कर देता है? –

41

क्या आपका अपलोड बहुत अंत में मर जाता है? दुर्घटनाग्रस्त होने से 99% पहले? क्लाइंट बॉडी और बफर महत्वपूर्ण हैं क्योंकि nginx को आने वाले डेटा को बफर करना होगा। शरीर कॉन्फ़िगर (अनुरोध निकाय का डेटा) निर्दिष्ट करता है कि कैसे nginx बहु-भाग-फ़ॉर्म क्लाइंट से बाइनरी डेटा के थोक प्रवाह को आपके ऐप के तर्क में संभालता है।

clean सेटिंग किसी फ़ाइल में आने वाले बफर को स्टोर करने के लिए nginx को निर्देश देकर स्मृति और खपत सीमा को मुक्त करती है और फिर इसे हटाकर डिस्क से बाद में इस फ़ाइल को साफ़ करती है।

body_in_file_only से clean पर सेट करें और client_max_body_size के लिए बफर समायोजित करें।मूल प्रश्न की कॉन्फ़िगरेशन पर पहले से ही भेज दिया गया था, टाइमआउट भी बढ़ाएं। मैं इसे ठीक करने के लिए नीचे दी गई सेटिंग्स का उपयोग करता हूं, आपके स्थानीय कॉन्फ़िगरेशन, सर्वर, & http संदर्भों में उपयुक्त है।

client_body_in_file_only clean; 
client_body_buffer_size 32K; 

client_max_body_size 300M; 

sendfile on; 
send_timeout 300s; 
+0

भले ही यह nginx उचित HTTP 413 लौटाने के परिणामस्वरूप, UA अभी भी अनुरोध निकाय की पूरी तरह से भेजना समाप्त कर देगा, है ना? उस मामले में मुझे लगता है कि दृष्टिकोण @ जो-शॉ सुझाव का प्रयास करने लायक है। – krukid

+0

@krukid जब ऐसा लगता है कि हमें एनजीआईएनएक्स "तेजी से विफल होने से पहले 99% अपलोड पूरा हो गया," मैं आपसे सहमत हूं। इस मामले में, सभी संकेत अनुरोध ऑब्जेक्ट के आस-पास सकारात्मक हैं, यानी निदान यह है कि आंतरिक सर्वर अनुप्रयोग तर्क ठीक है - जो भी Nginx के पीछे चलता है। इसलिए जब संभव है कि अनुरोध अच्छी तरह से बनाया गया है, तो हमारी आवश्यकता यह है कि क्यों एनजीआईएनएक्स प्रतिक्रिया पर चकित करता है। client_max_body_size हमारे द्वारा देखे जाने वाले पहले कॉन्फ़िगरेशन विकल्प होना चाहिए, फिर बफर पर विचार करें, क्योंकि पर्याप्त पर्याप्त अपलोड के साथ सही समाधान इस बात पर निर्भर करता है कि हमारे सर्वर कितनी मेमोरी को संभाल सकता है। –

+0

@ बेंट कार्डन। यह दृष्टिकोण बेहतर था और मैंने कोशिश की। लेकिन मुझे अभी भी 4 एमबी फ़ाइल के लिए लगभग 20 सेकंड के बाद 413 त्रुटि मिल रही है। मेरे upspeeds 20secs में 4 एमबी का प्रबंधन नहीं कर सकते हैं, इसलिए यह डेटा हो रहा है जब डेटा काफी हद तक बह रहा है। विचार? – Jerome