Request: त्रुटि: प्रतिक्रिया से डेटा उत्सर्जित होने के बाद आप पाइप नहीं कर सकते।

इसे भी इसी तरह की परिस्थितियों में देख रहे हैं।

मुझे नहीं पता कि इसके और क्या निहितार्थ हो सकते हैं, लेकिन मैं request.js को निम्नानुसार बदलकर इस समस्या को हल करने में सक्षम हूं:

जोड़ें:

var superOn = Request.prototype.on;
Request.prototype.on = function (eventName) {
  if (eventName === "data") {
    this.resume()
  }
  superOn.apply(this, arguments)
}

और dataStream.on("data" कॉल को इसमें बदलें:

dataStream.on("data", function (chunk) {
      var emitted = self.emit("data", chunk)
      if (emitted) {
        self._destdata = true
      } else {
        // pause URL stream until we pipe it
        dataStream.pause()
        dataStream.unshift(chunk)
      }
})

मूल मुद्दा (मुझे लगता है कि) वह यह है कि onResponse बुला रहा है resume() और एक "डाटा" श्रोता, जो दोनों के बहने डेटा शुरू संलग्न है, लेकिन हम अभी तक यह पाइप के लिए तैयार नहीं हो सकता है। तो मेरा समाधान यह है कि यदि हम डेटा उत्सर्जित करने का प्रयास करते हैं लेकिन हमारे पास अभी तक कोई श्रोता नहीं है, तो हम अंतर्निहित रीडस्ट्रीम को तब तक रोक देते हैं जब तक हमें डेटा श्रोता संलग्न नहीं हो जाता।

अच्छा होगा अगर कोई और इस समाधान का परीक्षण कर सके और सत्यापित कर सके कि यह काम करता है।

नहीं, मेरे लिए काम नहीं करता। इस मुद्दे पर गतिविधि की कमी के कारण, मैं बस request का उपयोग बंद करने जा रहा हूं और Node.js http मॉड्यूल पर वापस जा रहा हूं।

मुझे यह उल्लेख करना चाहिए कि मेरा फिक्स अनुरोध 2.37.0.0.1 के लिए है। यह पुराने रिलीज के साथ काम नहीं करेगा।

@aldeed मैंने रिपॉजिटरी को फोर्क किया है और आपका फिक्स लागू किया है: https://github.com/joepie91/request। भविष्य में यह (मूल) भंडार किस हद तक बनाए रखा जाता है, इस पर निर्भर करते हुए, मैं वहां और अधिक सुधारों को मर्ज कर सकता हूं। मैं अभी तक निश्चित नही हूं।

मैं इस मुद्दे को कुछ घंटों के लिए डिबग कर रहा था, लेकिन जब तक मैं इस धागे को नहीं पढ़ता तब तक समाधान नहीं ढूंढ पा रहा था। यह समस्या क्यों हो रही है, इसके बारे में कुछ और तकनीकी पृष्ठभूमि की जानकारी इस प्रकार है। इसका पालन करना आसान बनाने के लिए यह थोड़ा सरल है।

request इस अर्थ में 'स्ट्रीमिंग एपीआई' प्रदान करता है कि आप .pipe मूल अनुरोध ऑब्जेक्ट को WritableStream । हालांकि, चूंकि यह अनुरोध ऑब्जेक्ट प्रतिक्रिया स्ट्रीम नहीं है, request 'shims' data ईवेंट - यह प्रतिक्रिया स्ट्रीम पर data ईवेंट के लिए श्रोता बनाता है, और फिर इस घटना को फिर से उत्सर्जित करता है, इस प्रकार अनुरोध वस्तु को स्ट्रीम के रूप में कार्य करने में सक्षम होता है।

केवल एक ही समस्या है: जैसे ही आप किसी स्ट्रीम के data ईवेंट से जुड़ते हैं, वह प्रवाहित होने लगती है ।

अब यह आम तौर पर कोई मुद्दा नहीं है; Node.js 'टिक' के साथ काम करता है - दुभाषिया में उन्हें 'साइकिल' मानें। सरलीकृत व्याख्या यह है कि कोड का एक ब्लॉक 'टिक' का उपभोग करेगा, और अगली टिक तक कोई भी ईवेंट चेक या सक्रिय नहीं किया जाएगा। इसका मतलब है कि निम्नलिखित काल्पनिक कोड ठीक काम करेगा:

stream = getSomeRequestStream();
stream.pipe(target);

दोनों पंक्तियों को एक ही टिक में निष्पादित किया जाता है, और पहली data घटना संभवतः अगले टिक तक नहीं हो सकती है - इस तरह दुभाषिया आंतरिक रूप से काम करता है। इसका मतलब है कि आपके पास इस बात की गारंटी है कि .pipe को पहले data ईवेंट के _before_ संसाधित किया जाता है, और सब कुछ अपेक्षा के अनुरूप काम करेगा।

अब, जो-स्पैनिंग ने जो करने का प्रयास किया वह एक अतुल्यकालिक निर्माण का उपयोग था, इस विशेष उदाहरण में एक टाइमआउट। स्ट्रीम इनिशियलाइज़ेशन और .pipe अब कोड के एक ही ब्लॉक में मौजूद नहीं हैं।

एसिंक्रोनस निर्माण घटनाओं के समान नियम का पालन करते हैं - वे संभवतः अगले टिक तक निष्पादित नहीं हो सकते हैं। हालांकि, जब तक आपका एसिंक्रोनस निर्माण निष्पादित होता है, तब तक घटना चक्र समाप्त हो चुका होता है और पहला data ईवेंट _already_ निकाल दिया जाता है - डेटा का आपका पहला हिस्सा स्ट्रीम इनिशियलाइज़ेशन और आपके .pipe बीच के अंतराल में आता है। request पता लगाता है कि एक data ईवेंट पहले ही सक्रिय हो चुका है, और आपको बताता है कि अब आप .pipe स्ट्रीम नहीं कर सकते क्योंकि यह पहले ही प्रवाहित हो चुकी है।

यही समस्या _anything_ के लिए होती है जो स्ट्रीम आरंभीकरण के बाद कम से कम एक टिक बाद में होती है।

@aldeed द्वारा समाधान यह जांच कर ठीक करता है कि अनुरोध ऑब्जेक्ट से कोई श्रोता जुड़ा हुआ है या नहीं, और यदि नहीं, तो डेटा का हिस्सा मूल स्ट्रीम में वापस रखकर और उस मूल स्ट्रीम को रोक देता है - इस प्रकार इसे बहने से रोकता है। एक बार श्रोता संलग्न होने के बाद, यह मूल स्ट्रीम को फिर से शुरू कर देता है, और इस बार एक data ईवेंट हैंडलर सुनना होगा।

जिस तरह से data इवेंट शिम request में काम करता है वह वास्तव में एक डिज़ाइन दोष है। यह इस संभावना को ध्यान में नहीं रखता है कि एक ही टिक में स्ट्रीम इनिशियलाइज़ेशन और पाइपिंग नहीं हो सकती है, और यह कि Node.js एक स्वाभाविक रूप से एसिंक्रोनस प्लेटफॉर्म है (इस प्रकार, इस तरह की स्थितियों की अपेक्षा की जाती है)। हालांकि यह फिक्स काम करता है, और मज़बूती से काम करना चाहिए, एक बेहतर समाधान यह होगा कि मूल स्ट्रीम पर data ईवेंट के लिए बाइंडिंग को तब तक स्थगित किया जाए, जब तक कि पहला श्रोता संलग्न न हो जाए।

एक आखिरी नोट; यदि आप अपने अनुरोध के आरंभीकरण में कॉलबैक परिभाषित करते हैं, तो यह सुधार काम नहीं करेगा।

आंतरिक रूप से, यदि कॉलबैक की आपूर्ति की जाती है, तो request एक data ईवेंट हैंडलर को स्वयं से जोड़ देगा, बॉडी को पढ़ेगा, और आपके कॉलबैक को बॉडी की आपूर्ति करेगा। इसके आस-पास का तरीका, इसके बजाय response ईवेंट से अटैच करना है (और कॉलबैक निर्दिष्ट नहीं करना है)। प्रतिक्रिया प्राप्त होते ही यह घटना (विश्वसनीय रूप से) सक्रिय हो जाएगी और अनुरोध स्ट्रीमिंग के लिए तैयार है।

@aldeed मैं इसे घंटों तक ठीक करने की कोशिश कर रहा हूं, वास्तव में इसे ठीक करने के मेरे सभी प्रयास विफल हो रहे हैं, और अब मैं अंततः अपनी चीज़ पर काम करना जारी रख सकता हूं। मुझ पर आपकी एक बीयर उधार है :)

इस मुद्दे के बारे में एक त्वरित नोट क्योंकि यह नई शैली की धारा और 3.0 शाखा से संबंधित है।

नई शैली की पठनीय धाराओं के साथ उन्हें "रोका हुआ और बफरिंग" स्थिति माना जा सकता है, जब तक वे read() से बाहर नहीं हो जाते, तब तक वे डेटा को बाहर नहीं जाने देंगे।

इसका मतलब है कि हमें अगले टिक () हैक में से अधिकांश को छोड़ना होगा। मैंने इसे अन्य पुस्तकालयों में थोड़ा सा निपटाया है और हमें जो करना होगा वह पहले पढ़ने के लिए प्रतीक्षा करें() और फिर सभी "आलसी" कोड को ट्रिगर करें।

एक स्पष्ट परिणाम यह है कि 3.0 में यदि आप कॉलबैक पास करते हैं तो यह सभी सामग्री को बफर कर देगा। वर्तमान में, यदि आप स्ट्रीमिंग एपीआई का उपयोग करते हैं तो यह बफरिंग को अक्षम कर देता है लेकिन अगली टिक हैक के बिना हम इसका अनुमान नहीं लगा सकते हैं।

@mikael क्या आप इस फिक्स को वर्तमान मास्टर शाखा के लिए पुल अनुरोध के रूप में स्वीकार करेंगे?

इसका मूल्यांकन करने के लिए मुझे इसे पीआर के रूप में देखना होगा।

ठीक है। वास्तविक पुल अनुरोध निर्माण को @aldeed तक छोड़ना शायद सबसे अच्छा है, यह देखते हुए कि उसने मूल फिक्स में योगदान दिया है - इसे मुख्य भंडार में विलय करना शायद उसकी पसंद, लाइसेंसिंग-वार और वह सब कुछ होना चाहिए।

धन्यवाद, @ जोपी 91। @mikeal , जैसा कि मुझे याद है, जिस तरह से मैंने 2.37.0 में कोड पढ़ा, यह पहले से ही नई शैली की धाराओं का उपयोग कर रहा है, इसलिए वे "रोके और बफर" हैं, जैसा कि आप कहते हैं, शुरुआत में। समस्या तब आती है जब आप अपना खुद का "डेटा" श्रोता संलग्न करते हैं और फिर से शुरू करते हैं, जो आप अलग-अलग जगहों पर करते हैं, क्योंकि ये रीडस्ट्रीम को खुद को रोकने के लिए कहते हैं। तो जैसा कि @ joepie91 कहते हैं, एक सच्चे समाधान के लिए आंतरिक को फिर से इंजीनियरिंग करने की आवश्यकता होगी जैसे कि आप "डेटा" श्रोता को संलग्न नहीं करते हैं।

डॉक्स से :

नोड v0.10 में, नीचे वर्णित पठनीय वर्ग जोड़ा गया था। पुराने नोड प्रोग्राम के साथ पश्च संगतता के लिए, जब कोई 'डेटा' ईवेंट हैंडलर जोड़ा जाता है, या जब पॉज़ () या फिर से शुरू () विधियों को कॉल किया जाता है, तो रीडेबल स्ट्रीम "फ्लोइंग मोड" में स्विच हो जाती है। प्रभाव यह है कि, भले ही आप नई रीड () विधि और 'पठनीय' घटना का उपयोग नहीं कर रहे हों, फिर भी आपको 'डेटा' भाग खोने के बारे में चिंता करने की आवश्यकता नहीं है।

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

ठीक है, मैंने शायद गलत पढ़ा है या मैं गलत याद कर रहा हूं या मैंने 3.0 कोड भी देखा, और भ्रमित हो गया। :)

सबसे तेज़ समाधान stream.PassThrough() ऑब्जेक्ट पर तुरंत पाइप करना हो सकता है
आपको बिना किसी समस्या के बाद में किसी भी समय पासथ्रू ऑब्जेक्ट से पाइप करने में सक्षम होना चाहिए।
देखें: http://nodejs.org/api/stream.html#stream_class_stream_passthrough

@ZJONSSON मैंने किसी बिंदु पर कोशिश की, लेकिन यह भी काम नहीं किया। जहां तक ​​मैं समझता हूं, यह किसी भी अन्य प्रकार की स्ट्रीम के समान सीमा (बाद में स्ट्रीम अटैचमेंट से पहले उत्सर्जित डेटा का पुन: उत्सर्जन नहीं) के लिए प्रवण है, इसलिए यदि आप मूल अनुलग्नक request और request ऑब्जेक्ट से आपका अपना लगाव एक ही टिक में नहीं होता है।

@ joepie91 मूल उदाहरण को शीर्ष पर ले जाना और तुरंत एक PassThrough पर पाइप करना बिना किसी समस्या के चलता है। शायद मैं इस मुद्दे को गलत समझ रहा हूँ?

var fs = require('fs'),
  request = require('request');

var readStream = request({
  url: 'https://gist.githubusercontent.com/joe-spanning/6902070/raw/8967b351aec744a2bb51c16cb847c44636cf53d9/pipepromise.js'
})
.pipe(require('stream').PassThrough());  // this line is the only modification

// wait for 5 seconds, then pipe
setTimeout(function() {

  var writeStream = readStream.pipe(fs.createWriteStream('test.js'));

  writeStream.on('finish', function() {
    console.log('all done!');
  });

  writeStream.on('error', function(err) {
    console.error(err);
  });

}, 5000);

ईमानदारी से कहूं तो मुझे कुछ पता नहीं है। अगर मुझे सही से याद है, तो मैंने ठीक यही कोशिश की, और इससे कोई फायदा नहीं हुआ। क्या इस बीच शायद request में अंतर्निहित कोड बदल गया है?

मुझे यह जोड़ना चाहिए कि आपने जो उदाहरण संशोधित किया है वह वास्तव में @ जो-स्पैनिंग का है। मुझे यकीन नहीं है कि उसमें और मेरे कोड के बीच कोई अंतर हो सकता है जो इसे केवल उसके मामले में काम करता है।

Submitted PR #1098

आंतरिक रूप से, यदि कॉलबैक की आपूर्ति की जाती है, तो अनुरोध डेटा ईवेंट हैंडलर को स्वयं से जोड़ देगा, बॉडी को पढ़ेगा, और बॉडी को आपके कॉलबैक में आपूर्ति करेगा। इसके आस-पास का तरीका, प्रतिक्रिया घटना से संलग्न करना है> (और कॉलबैक निर्दिष्ट नहीं करना)। प्रतिक्रिया प्राप्त होते ही यह घटना (विश्वसनीय रूप से) सक्रिय हो जाएगी और अनुरोध स्ट्रीमिंग के लिए तैयार है।

मुझे अभी-अभी request(url, mycb).pipe(mywstream) . ने काट लिया है
कभी-कभी mycb कहा जाता है, कभी-कभी नहीं।
शायद अनुरोध को चेतावनी देनी चाहिए कि पहले से सेट किए गए कॉलबैक के साथ pipe() का उपयोग करने से बचा जाना चाहिए?

मुझे एक ही समस्या है सिवाय, मुझे यह त्रुटि तब मिलती है जब मैं .pipe में .on('response') प्रयास करता हूं:

req = request(options)
req.on 'response', (response) ->
  # get info from headers here
  stream = createWriteStream file
  req.pipe stream

मेरी तरफ से अपडेट करें, मुझे यकीन नहीं है कि मैंने इसे पहले क्यों पोस्ट नहीं किया।

इस समस्या का समय पर समाधान नहीं होने और request में कई अन्य निराशाजनक बगों के चलते होने के कारण, मैंने कुछ समय पहले अपनी स्वयं की HTTP क्लाइंट लाइब्रेरी लिखी है जो इस उपयोगकेस से सही ढंग से निपटती है; bhttp । यह Streams2 समर्थन मुद्दों को भी हल करता है।

क्या इस पर कोई अपडेट है?

मुझे पता है कि यह मुद्दा पुराना है, लेकिन मेरे मामले में ( @dogancelik के समान, प्रतिक्रिया हेडर के आधार पर सशर्त रूप से प्रतिक्रिया को पाइप करना), मैं निम्नलिखित करने में सक्षम था:

const req = request.get(URL);
req.on('response', (response) => {
    response.pause();
    // Do stuff with response.statusCode etc.
    setTimeout(() => {
        response
        .pipe(process.stdout)
        ;
    }, 2000);
});

यानी, प्रतिक्रिया स्ट्रीम को रोकना ( request स्पष्ट रूप से स्ट्रीम को स्वचालित रूप से बहने वाले मोड में सेट करता है?) और प्रतिक्रिया ऑब्जेक्ट को स्वयं पाइप करना ( req )।

मैं इस बारे में मुझसे अधिक जानकार उपयोगकर्ताओं की प्रतिक्रिया का स्वागत करता हूँ।

बस इस पर भी ध्यान दें... मैंने इसे अपनी ओर से हल किया क्योंकि यह मेरे मामले में एक तार्किक त्रुटि थी।

मेरे पास एक वैश्विक सरणी है जहां मैं प्रत्येक अनुरोध को एक अद्वितीय आईडी के माध्यम से संग्रहीत करता हूं। मैं एक साथ कई अनुरोध चला रहा हूँ। मेरे पास अनुरोधों के लिए एक निरस्त विकल्प है। यह आपको और जानकारी दे सकता है;

unzipper = function() {
    var self = this;

    /**
     * Properties
     */
    this.req = [];
    this.aborted = [];
    /* */

    /**
     * Methods
     */
    this.download = function(id, onProgress, onSuccess, onError, onAbort){

        var newinstanceAbort = {
          id: id,
          abort: false
        };

        this.aborted.push(newinstanceAbort);

        var url = '...';
        var target = '...';

        var request = require('request');
        var j = request.jar();
        var progress = require('request-progress');
        var cookie = request.cookie(app.session.sessionName + '=' + app.session.sessionId);
        j.setCookie(cookie, url);

        var downloadRequest = {
          id: id,
          request: request({url: url, jar: j})
        };

        this.req.push(downloadRequest);

        var instanceRequest = app.findObject(this.req, id);
        var instanceAbort = app.findObject(this.aborted, id);

        progress(instanceRequest.request, {
            throttle: 10,
        })
        .on('progress', function (state) {
            var progress = Math.round(state.percent * 100);
            onProgress(progress);
        })
        .on('error', function (err) {
            onError(err);
        })
        .on('end', function (e) {
            if(instanceAbort.abort) {
                onAbort();
            } else {
                onSuccess();
            }

            /**
             * Remove the unique request object from the req to complete the request
             *
             * If this is not done, the request would throw "You cannot pipe after data has been emitted from the response" as it is constantly re-emitting the same request
             */
            self.complete(id);

        })
        .pipe(app.fs.createWriteStream(target));
    };



    this.abort = function(id){
        var instanceAbort = app.findObject(this.aborted, id);
        var instanceRequest = app.findObject(this.req, id);

        instanceRequest.request.abort();
        instanceAbort.abort = true;
    };

    this.complete = function(id){
        var index = this.req.map(function(x){ return x.id; }).indexOf(id);

        this.req.splice(index, 1);
    };
    /* */

};

@ जूलियन-सी अच्छी कॉल, यह वास्तव में ऐसा प्रतीत होता है क्योंकि response श्रोता को बाध्य करने से यह स्वचालित रूप से "फ्लोइंग मोड" में बदल जाता है। मैं सत्यापित कर सकता हूं कि यह [email protected] और [email protected] दोनों में हो रहा है।

सुनिश्चित नहीं है कि यह इरादा है या नहीं (मेरी समझ यह थी कि ऐसा नहीं है कि इसे कैसे काम करना चाहिए)। अभी के लिए, मैं स्ट्रीम को रोकने के समाधान का उपयोग करने की योजना बनाऊंगा (यदि मुझे रास्ते में कुछ भी नया मिलता है तो मैं यहां वापस पोस्ट करने का प्रयास करूंगा और याद रखूंगा)

मैं बेतरतीब ढंग से उपरोक्त टिप्पणी में डॉगेंसेलिक की तरह ही अनुभव कर रहा हूं: त्रुटि तब होती है जब प्रतिक्रिया हैंडलर के अंदर पाइपिंग होती है। लेकिन यह कैसे संभव हो सकता है? यदि आप request.js को देखते हैं, तो अनुरोध के अपने "डेटा" हैंडलर (जो परेशानी का कारण बनता है) बिल्कुल संलग्न होने से पहले "प्रतिक्रिया" घटना उत्सर्जित होती है:

self.emit('response', response)

self.dests.forEach(function (dest) {
  self.pipeDest(dest)
})

responseContent.on('data', function (chunk) {
  if (self.timing && !self.responseStarted) {
    self.responseStartTime = (new Date()).getTime()

    // NOTE: responseStartTime is deprecated in favor of .timings
    response.responseStartTime = self.responseStartTime
  }
  self._destdata = true
  self.emit('data', chunk)
})

चूंकि ईवेंट हैंडलर को सिंक्रोनस रूप से बुलाया जाता है, इसलिए मुझे उम्मीद है कि डेटा खपत होने से पहले पाइप संलग्न हो जाएगा।

मुझे निम्नलिखित कोड के साथ एक ही त्रुटि मिलती है:

let rp = require('request-promise');
let options = {uri: 'http://a-url-pointing-online-pdf-link'};

koaRouter.get('/api/url/download', async(ctx, next) => {
        try {
            ctx.set('Content-disposition', 'attachment;filename=a.pdf');
            ctx.body = rp(options);  
        } catch (e) {
            ctx.body = e;
        }
    })   

और मैं PassThrough का उपयोग करके आईडी के आसपास काम करता हूं, लेकिन मुझे नहीं पता कि त्रुटि क्यों आई, और मुझे यह भी नहीं पता कि passthrough हल होता है। मेरे सभी कोड को उसी 'टिक' में निष्पादित किया जाना चाहिए।

let rp = require('request-promise');
let stream = require('stream');
let options = {uri: 'http://a-url-pointing-online-pdf-link'};

koaRouter.get('/api/url/download', async(ctx, next) => {
        try {
            ctx.set('Content-disposition', 'attachment;filename=a.pdf');
            let pass = stream.PassThrough();
            rp(options).pipe(pass);
            ctx.body = pass;
        } catch (e) {
            ctx.body = e;
        }
    })   

अनुरोध वस्तु के लिए भी समान बग मौजूद है। यदि आपने इसे write किया है, तो आप इसे pipe नहीं कर सकते।

मैंने स्ट्रीम के लिए कोर http/https मॉड्यूल पर भी स्विच किया। यह आसान और विश्वसनीय है। तो धाराओं के लिए request की आवश्यकता नहीं है।

पाइप न करें दूरभाष प्रतिक्रिया हुईयह मेरे साथ ठीक काम करता है
`वर अनुरोध = आवश्यकता ('अनुरोध');
वर एफएस = आवश्यकता ('एफएस');
वर पथ = आवश्यकता ('पथ');

डाउनलोडफाइल (file_url, लक्ष्यपथ) {
// प्रगति जानने के लिए चर सहेजें

var _self = this;
var received_bytes = 0;
var total_bytes = 0;

var req = request({
    method: 'GET',
    uri: file_url
});

var out = fs.createWriteStream(targetPath);
**///////////////MOVE THIS LINE  FROM HERE TO ///////////////////

////////////// अनुरोध पर ('प्रतिक्रिया', समारोह (डेटा)///////
////////////////////////req.pipe (बाहर);//////////////// //////////////**

req.on('response', function ( data ) {
    **### req.pipe(out);**
    // Change the total bytes value to get progress later.
    total_bytes = parseInt(data.headers['content-length' ]);
});

req.on('data', function(chunk) {
    // Update the received bytes
    received_bytes += chunk.length;

    _self.showProgress(received_bytes, total_bytes);
    var percentage = (received_bytes * 100) / total_bytes;
    console.log(percentage + "% | " + received_bytes + " bytes out of " + total_bytes + " bytes.");

});

req.on('end', function() {
    alert("File succesfully downloaded");
});

}`

अनुरोध अब रखरखाव मोड में है और किसी भी नई सुविधाओं को मर्ज नहीं करेगा। अधिक जानकारी के लिए कृपया #3142 देखें।