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() 호출하고 "data" 리스너를 연결하는데, 둘 다 데이터 흐름을 시작하지만 아직 파이프할 준비가 되지 않았을 수 있습니다. 따라서 내 솔루션은 데이터를 내보내려고 하지만 아직 리스너가 없는 경우 데이터 리스너가 연결될 때까지 기본 읽기 스트림을 일시 중지하는 것입니다.

다른 사람이 이 솔루션을 테스트하고 작동하는지 확인할 수 있다면 좋을 것입니다.

아니, 나에게 효과가 없습니다. 이 문제에 대한 활동이 없기 때문에 request 사용을 중단하고 Node.js http 모듈로 돌아가겠습니다.

내 수정 사항은 요청 2.37.0에 대한 것임을 언급해야 합니다. 이전 릴리스에서는 작동하지 않습니다.

@aldeed 저장소를 분기하고 수정 사항을 적용했습니다: https://github.com/joepie91/request. 이 (원래) 저장소가 미래에 유지되는 정도에 따라 더 많은 수정 사항을 거기에 병합할 수 있습니다. 아직 확실하지 않다.

지금 몇 시간 동안 이 문제를 디버깅했지만 이 스레드를 읽을 때까지 솔루션을 찾을 수 없었습니다. 이 문제가 발생하는 이유에 대한 몇 가지 기술적인 배경 정보는 다음과 같습니다. 따라하기 쉽도록 조금 단순화했습니다.

request 제공하는 의미에서 '스트리밍 API'당신 수 .pipe A와 원래 요청 객체 WritableStream . 그러나 이 요청 객체는 응답 스트림 자체가 아니기 때문에 request 는 data 이벤트를 'shims'합니다 - 응답 스트림에 data 이벤트에 대한 리스너를 생성하고 그런 다음 이 이벤트를 자체적으로 다시 내보내므로 요청 개체가 스트림 자체로 작동하도록 할 수 있습니다.

단 하나의 문제가 있습니다. 스트림의 data 이벤트에 연결하자마자 흐르기 시작합니다 .

이제 이것은 일반적으로 문제가 되지 않습니다. Node.js는 '진드기'와 함께 작동합니다. 인터프리터에서 '주기'로 간주합니다. 간단한 설명은 코드의 한 블록이 '틱'을 소비하고 다음 틱까지 이벤트가 확인되거나 실행되지 않는다는 것입니다. 즉, 다음 가상 코드가 제대로 작동합니다.

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

두 줄 모두 동일한 틱에서 실행되며 첫 번째 data 이벤트는 다음 틱까지 발생할 수 없습니다. 이것이 인터프리터가 내부적으로 작동하는 방식입니다. 즉, .pipe 가 첫 번째 data 이벤트가 발생하기 _전에_ 처리되고 모든 것이 예상대로 작동한다는 것을 보장합니다.

이제 @joe-spanning이 시도한 것은 이 특정 예에서 시간 초과인 비동기 구조를 사용하는 것이었습니다. 스트림 초기화 및 .pipe 는 더 이상 동일한 코드 블록에 존재하지 않습니다.

비동기 구조는 이벤트와 동일한 규칙을 따릅니다. 다음 틱까지 실행할 수 없습니다. 그러나 비동기 구조가 실행될 때 이벤트 주기가 막 끝나고 첫 번째 data 이벤트가 _already_ 시작됩니다. 첫 번째 데이터 청크는 스트림 초기화와 .pipe 사이의 간격을 통해 들어옵니다. request 는 data 이벤트가 이미 발생했음을 감지하고 스트림이 이미 흐르기 시작했기 때문에 더 이상 .pipe 스트림을 사용할 수 없다고 알려줍니다.

스트림 초기화보다 한 틱 이상 늦게 발생하는 _anything_에 대해서도 이와 동일한 문제가 발생합니다.

@aldeed 의 솔루션은 요청 객체에 연결된 리스너가 있는지 확인하고 그렇지 않은 경우 데이터 청크를 원래 스트림에 다시 넣고 원래 스트림을 일시 중지하여 이 문제를 수정하여 흐름을 중지합니다. 리스너가 연결되면 원래 스트림을 재개하고 이번에는 data 이벤트 핸들러가 수신합니다.

data 이벤트 shim이 request 에서 작동하는 방식은 실제로 설계 결함입니다. 스트림 초기화 및 파이핑이 동일한 틱에서 발생하지 않을 수 있고 Node.js가 본질적으로 비동기식 플랫폼이라는 가능성을 고려하지 않았습니다(따라서 이러한 종류의 상황이 예상됨). 이 수정이 작동하고 안정적으로 작동해야 하지만 더 나은 솔루션은 첫 번째 수신기가 연결될 때까지 원래 스트림의 data 이벤트에 대한 바인딩을 연기하는 것입니다.

마지막 참고 사항입니다. 요청 초기화에서 콜백을 정의하면 이 수정 사항이 작동하지 않습니다.

내부적으로 콜백이 제공되면 request 는 data 이벤트 핸들러를 자체에 첨부하고 본문을 읽고 콜백에 본문을 제공합니다. 이 문제를 해결하는 방법은 대신 response 이벤트에 연결하고 콜백을 지정하지 않는 것입니다. 이 이벤트는 응답이 수신되고 요청이 스트리밍할 준비가 되는 즉시 (안정적으로) 발생합니다.

@aldeed 몇 시간 동안 이 문제를 해결하려고 노력했지만 실제로 문제를 해결하려는 모든 시도는 실패했으며 이제 마침내 내 작업을 계속할 수 있습니다. 나는 당신에게 맥주를 빚지고 있습니다 :)

새로운 스타일의 스트림 및 3.0 분기와 관련된 이 문제에 대한 간략한 메모입니다.

새로운 스타일의 읽기 가능한 스트림을 사용하면 "일시 중지 및 버퍼링" 상태로 간주될 수 있는 상태로 열리며 read() 가 될 때까지 데이터를 내보내지 않습니다.

이것은 우리가 대부분의 nextTick() 해킹을 버려야 한다는 것을 의미합니다. 나는 이것을 다른 라이브러리에서 조금 다루었고 우리가 해야 할 일은 첫 번째 read()를 기다린 다음 모든 "게으른" 코드를 트리거하는 것입니다.

한 가지 분명한 결과는 3.0에서 콜백을 전달하면 모든 내용을 버퍼링한다는 것입니다. 현재 스트리밍 API에 액세스하면 버퍼링이 비활성화되지만 nextTick 해킹 없이는 이를 유추할 수 없습니다.

@mikael 현재 마스터 브랜치에 대한 풀 요청으로 이 수정 사항을 수락하시겠습니까?

그것을 평가하려면 PR로 보아야 합니다.

괜찮은. 그가 원래 수정에 기여했다는 점을 감안할 때 실제 pull 요청 생성을 @aldeed 에게 맡기는 것이 가장 좋습니다. 기본 저장소에 병합하는 것이 라이선싱 측면에서 그의 선택일 것입니다.

@joepie91 감사합니다. @mikeal , 내가 기억하는 것처럼 2.37.0에서 코드를 읽는 방식은 이미 새로운 스타일의 스트림을 사용하고 있으므로 처음에는 "일시 중지 및 버퍼링"됩니다. 문제는 자신의 "데이터" 리스너를 연결하고 재개를 호출할 때 발생합니다. 이 작업은 readstream에 일시 중지를 해제하도록 지시하기 때문에 다른 위치에서 수행합니다. @joepie91이 말했듯이 진정한 솔루션은 "데이터" 리스너를 연결하지 않도록 내부를 재설계해야 합니다.

문서에서 :

Node v0.10에서는 아래와 같이 Readable 클래스가 추가되었습니다. 이전 Node 프로그램과의 호환성을 위해 'data' 이벤트 핸들러가 추가되거나 pause() 또는 resume() 메서드가 호출될 때 Readable 스트림이 "흐름 모드"로 전환됩니다. 결과는 새로운 read() 메서드와 'readable' 이벤트를 사용하지 않더라도 더 이상 'data' 청크 손실에 대해 걱정할 필요가 없다는 것입니다.

2.37은 확실히 새로운 스타일의 스트림을 사용 하지 않습니다. :) 데이터 이벤트를 내보내기 전에 요청 개체를 대상으로 파이프 해야 합니다. 마찬가지로, 당신이해야합니다 같은 진드기에 요청 인스턴스에 파이프 당신이 그것을 만들거나 다른 유사한 트릭 (우리가 시도하고 경우에 따라이 문제를 완화하기 위해 몇 가지 코드를 가지고 있지만, 전부는 아니지만) 실패합니다.

좋아, 내가 잘못 읽었거나 잘못 기억하고 있거나 3.0 코드도보고 혼란스러워했습니다. :)

가장 빠른 수정은 stream.PassThrough() 개체에 즉시 파이프하는 것입니다.
나중에 문제 없이 통과 개체에서 파이프할 수 있어야 합니다.
참조: http://nodejs.org/api/stream.html#stream_class_stream_passthrough

@ZJONSSON 어느 시점에서 시도했지만 작동하지 않았습니다. 내가 이해하는 한, 다른 종류의 스트림과 동일한 제한(나중 스트림 첨부 이전에 방출된 데이터 재방출 없음)이 발생하기 쉬우므로 원본 첨부 파일이 request 경우 여전히 중단됩니다. request 개체에 대한 자신의 첨부 파일은 동일한 틱에서 발생하지 않습니다.

@joepie91 맨 위에 있는 원본 예제를 가져

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 의 기본 코드가 변경되었을 수 있습니까?

수정한 예제가 실제로 @joe-spanning의 예제임을 추가해야 합니다. 그의 경우에만 작동하는 코드와 차이점이 있는지 확실하지 않습니다.

제출된 PR #1098

내부적으로 콜백이 제공되면 요청은 데이터 이벤트 핸들러를 자체에 연결하고 본문을 읽고 본문을 콜백에 제공합니다. 이 문제를 해결하는 방법은 대신 >(콜백을 지정하지 않음) 응답 이벤트에 연결하는 것입니다. 이 이벤트는 응답이 수신되고 요청이 스트리밍할 준비가 되는 즉시 (안정적으로) 발생합니다.

방금 request(url, mycb).pipe(mywstream) 물렸습니다.
때로는 mycb가 호출되고 때로는 호출되지 않습니다.
콜백이 이미 설정된 pipe() 사용을 피해야 한다는 요청이 있을 수 있습니까?

.pipe in .on('response') 시도할 때 이 오류가 발생한다는 점을 제외하면 동일한 문제가 있습니다.

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

내 쪽에서 업데이트, 왜 전에 이것을 게시하지 않았는지 확실하지 않습니다.

이 문제가 시의 적절하게 해결되지 않고 request 의 다른 여러 실망스러운 버그에 걸쳐 실행되기 때문에 얼마 전에 이 사용 사례를 올바르게 처리하는 자체 HTTP 클라이언트 라이브러리를 작성했습니다. bhttp . 또한 Streams2 지원 문제도 해결합니다.

이에 대한 업데이트가 있습니까?

나는 이 문제가 오래 되었다는 것을 알고 있지만 제 경우에는(

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 아님).

이에 대해 나보다 지식이 풍부한 사용자의 피드백을 환영합니다.

이것도 한번 접해보세요... 제 경우에는 논리적 오류였기에 끝에서 해결했습니다.

고유 ID를 통해 각 요청을 저장하는 전역 배열이 있습니다. 여러 요청을 동시에 실행하고 있습니다. 요청에 대한 중단 옵션이 있습니다. 이렇게 하면 더 많은 정보를 얻을 수 있습니다.

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);
    };
    /* */

};

@julien-c 좋은 전화입니다. response 수신기를 바인딩하면 자동으로 "흐름 모드"로 전환되기 때문인 것 같습니다. [email protected] 및 [email protected] 모두에서 발생하는지 확인할 수 있습니다.

이것이 의도된 것인지 아닌지 확실하지 않습니다(내 이해는 이것이 작동하는 방식이 아니라는 것입니다). 지금은 스트림을 일시 중지하는 해결 방법을 사용할 계획입니다(진행 중에 새로운 내용을 발견하면 여기에 다시 게시하도록 노력하겠습니다)

위의 주석 에서 dogancelik와 같은 것을 무작위로 경험하고 있습니다. 응답 처리기 내부에서 파이프할 때 오류가 발생합니다. 그러나 이것이 어떻게 가능합니까? request.js를 보면 "response" 이벤트는 요청 자체의 "data" 핸들러(문제를 일으키는)가 전혀 첨부되기 전에 발생합니다:

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 를 사용하여 id를 처리하지만 오류가 발생한 이유를 모르고 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 가 필요하지 않습니다.

전화하지 마세요 응답이 발생했습니다이것은 나와 잘 작동합니다
` var 요청 = require('요청');
var fs = 요구('fs');
var 경로 = 요구('경로');

다운로드 파일(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 ///////////////////

/////////////// BE INSIDE req.on('응답', 함수( 데이터 )///////
/////////////////////////req.pipe(out);/////// /////////// //////////////**

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를 참조하십시오.