<p>request.get se bloquea con "El contenido del encabezado contiene caracteres no válidos"</p>

Creado en 8 mar. 2016  ·  20Comentarios  ·  Fuente: request/request

Prueba esto:

require('request').get('http://www.test.com/אבגד.pdf');

Después de unos milisegundos, esto se bloquea con TypeError('The header content contains invalid characters')

Ahora, si lo envuelvo en encodeURI , tiene éxito.
Pero si recibimos direcciones URL de una fuente externa, pueden estar codificadas o no. ¿Existe algún tipo de mecanismo incorporado para lidiar con esto? (Aparte de hacer encodeURI(decodeURI(url)) )

Comentario más útil

La cuestión es que, si bien es fácil solucionar esto, request debería detectar el error y propagarlo a través de los controladores de errores. Actualmente, se lanza como una excepción no detectada que puede causar bloqueos del servidor bastante graves de los que nunca podrá recuperarse porque no puede intentar / detectar esto manualmente.

Entonces yo diría que este es un error bastante severo en request . El error debe propagarse.

Todos 20 comentarios

Además, no encontré forma de detectar esa excepción. No importa si hay un try-catch o .on('error', ...

Recibo el mismo error con la versión 0.12.12 de Node y superior. El mismo código funciona con 0.12.9:

_http_outgoing.js:355
      throw new TypeError('The header content contains invalid characters');
            ^
TypeError: The header content contains invalid characters
    at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:355:13)
    at new ClientRequest (_http_client.js:101:14)
    at Object.exports.request (http.js:49:10)
    at Object.exports.request (https.js:136:15)
    at Request.start (//application/node_modules/request/request.js:747:30)
    at Request.end (/application/node_modules/request/request.js:1381:10)
    at end (/application/node_modules/request/request.js:575:14)
    at Immediate._onImmediate (/application/node_modules/request/request.js:589:7)
    at processImmediate [as _immediateCallback] (timers.js:367:17)

Resulta que en mi caso estaba enviando un salto de línea en una cookie. Tuve que quitarlo.

No, mi caso es simple, sin cookies, sin encabezados adicionales.

Tengo el mismo problema, usando https://github.com/matt-major/do-wrapper cuando intento acceder a la información de mi cuenta.

_http_outgoing.js:348
    throw new TypeError('The header content contains invalid characters');
    ^

TypeError: The header content contains invalid characters
    at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:348:11)
    at new ClientRequest (_http_client.js:85:14)
    at Object.exports.request (http.js:31:10)
    at Object.exports.request (https.js:197:15)
    at Request.start (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:746:30)
    at Request.write (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:1345:10)
    at end (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:560:16)
    at Immediate._onImmediate (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:588:7)
    at processImmediate [as _immediateCallback] (timers.js:383:17)

La cuestión es que, si bien es fácil solucionar esto, request debería detectar el error y propagarlo a través de los controladores de errores. Actualmente, se lanza como una excepción no detectada que puede causar bloqueos del servidor bastante graves de los que nunca podrá recuperarse porque no puede intentar / detectar esto manualmente.

Entonces yo diría que este es un error bastante severo en request . El error debe propagarse.

He invertido unas buenas 2 horas tratando de solucionar este problema, por lo que escribir un caso de prueba de reproducción fue bastante trivial.
Llegué a la conclusión de que, con mi conocimiento actual del código base, no se puede arreglar a menos que la validación se agregue a https://github.com/request/caseless , que por cierto me costó unos sólidos 20-30 minutos descubrir que en realidad es self.setHeader . Ese comportamiento no está documentado en caseless , ni es obvio por el nombre que se ocupa de configurar y obtener encabezados, y tampoco se espera que caseless.httpify(self, self.headers) parchee el objeto con setHeader .

try/catch en el punto donde se crea el objeto de solicitud es prácticamente imposible de recuperar porque no hay una forma sencilla de abortar la ejecución en ese momento. self.req.end seguirá llamando a

Para ser franco, me asusta que mis servicios de producción se basen en una biblioteca con un archivo principal de 1,4k de líneas en el que la lógica es tan complicada que algo tan fácil como propagar un error de un try / catch es prácticamente imposible sin estudiar profundamente todo el contenido. rube goldberg máquina de eventos. Es hora de alejarse de esto.

Esto también afecta al Nodo 5.6.0 y superior, que tiene una validación de encabezado más estricta: https://github.com/nodejs/node/blob/v5.6.0/CHANGELOG.md

Arreglado aquí https://github.com/request/request/pull/2164

Eche un vistazo a la prueba sobre cómo manejar el error en su código.

Parece que manejar el error es como de costumbre, con un evento .on('error', ... . ¡Bien!

Esto hará que el request más a prueba de balas, sin bloquear la aplicación en cosas estúpidas en el futuro.

Bueno, ahora me siento como un idiota increíblemente tonto.
De hecho, tenía exactamente la misma solución lista y mis pruebas fallaban constantemente.
Resulta que en mi 'caso de prueba trivial' olvidé llamar a t.end() .

Mis disculpas, la próxima vez solo publicaré mi rama y pediré comentarios.

@TimBeyer no hay problema, la versión 2.71 se publica con la solución: +1:

@simov La versión 2.71 ha solucionado el problema parcialmente para mí, aquí está mi escenario: estoy enviando una solicitud de publicación y obteniendo datos como fragmentos,

request({
              method: 'POST',
              headers: {
                 'test': 'אבגד'
              },
              uri: apiUrl,
              qs: req.query,
              json: req.body,
              gzip: true
            }
            , function(error, response, body) {
               console.log('callback')
            })
            .on('response', function (response) {
             console.log(response)
            })
            .on('error', function (err) {
              console.log(err);
            });

Cuando ejecuto esto, aparece un error

return self.req.write.apply(self.req, arguments)
                 ^

TypeError: Cannot read property 'write' of undefined
    at Request.write (/Users/muhammadkhurrumqureshi/Workspace/www/node_modules/request/request.js:1385:18)
    at end (/Users/muhammadkhurrumqureshi/Workspace/www/node_modules/request/request.js:565:18)
    at Immediate._onImmediate (/Users/muhammadkhurrumqureshi/Workspace/www/node_modules/request/request.js:594:7)
    at processImmediate [as _immediateCallback] (timers.js:383:17)

¿Puedes ayudar amablemente en esto?

@khurrumqureshi arreglado aquí https://github.com/request/request/pull/2165 : +1:

Básicamente, la misma verificación que en el método end . La razón es porque se está llamando a start en la línea anterior, y hasta ahora no se esperaba que se lanzara. Cuando su solicitud tiene un cuerpo write se llama antes de end , de ahí el error.

@simov : +1:

Aquí igual.

TypeError: The header content contains invalid characters
    at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:348:11)
    at new ClientRequest (_http_client.js:85:14)
    at Object.exports.request (http.js:31:10)
    at Object.exports.request (https.js:199:15)
    at Request.start (/home/mymodule/node_modules/request/request.js:744:32)
    at Request.end (/home/mymodule/node_modules/request/request.js:1433:10)
    at end (/home/mymodule/node_modules/request/request.js:566:14)
    at Immediate.<anonymous> (/home/mymodule/node_modules/request/request.js:580:7)
    at runCallback (timers.js:570:20)
    at tryOnImmediate (timers.js:550:5)

Los encabezados de respuesta son:

headers:
      { 'x-backside-transport': 'OK OK,FAIL FAIL',
        connection: 'close',
        'transfer-encoding': 'chunked',
        'x-dp-local-file': 'true',
        'x-client-ip': '127.0.0.1,176.31.126.162',
        'x-global-transaction-id': '145630106',
        date: 'Tue, 08 Nov 2016 01:03:59 GMT',
        'www-authenticate': 'Basic realm="Gateway(Log-in)"',
        'x-archived-client-ip': '127.0.0.1',
        'content-type': '',
        'x-dp-tran-id': 'gateway' },
     rawHeaders:
      [ 'X-Backside-Transport',
        'OK OK,FAIL FAIL',
        'Connection',
        'close',
        'Transfer-Encoding',
        'chunked',
        'x-dp-local-file',
        'true',
        'X-Client-IP',
        '127.0.0.1,176.31.126.162',
        'X-Global-Transaction-ID',
        '145630106',
        'Date',
        'Tue, 08 Nov 2016 01:03:59 GMT',
        'WWW-Authenticate',
        'Basic realm="Gateway(Log-in)"',
        'X-Archived-Client-IP',
        '127.0.0.1',
        'Content-Type',
        '',
        'X-DP-Watson-Tran-ID',
        'gateway' ]

Los encabezados de la solicitud son:

{ accept: 'application/json',
     authorization: 'Basic ...g==',
     referer: 'https://hostname.com/classify?text=%20So%20happy%20with%20this%20👍👍👍👍👍',
     host: 'gateway.myclass.net' }

Como puede ver, la solicitud contiene 3 veces un carácter especial <U+1F44D> .

¿Podría ser ese el problema?

Parece que el módulo node.js https no lo admite.

En caso de que alguien más tuviera el mismo problema que yo, tuve este error con aws-sdk y me estaba volviendo loco durante horas. Resultó ser un carácter PrvScan \u001b[5~ que, por alguna razón, estaba al acecho en mi archivo ~/.aws/credentials , que se propagó al encabezado de autorización utilizado por las solicitudes de AWS. El error solo apareció en mi máquina con Windows 7, por lo que probablemente fue algo relacionado con la forma en que se recuperó el archivo de credenciales de mi cuenta de AWS y algunas codificaciones de caracteres de Windows. Tampoco estaba visible cuando cat ing el archivo de credenciales, pero se hizo visible una vez que abrí el archivo con vi .

Sí, solo tuve el mismo problema. Me tomó unas horas resolverlo, debo admitirlo.
estaba usando MINGW64 (Git Bash) en una máquina con Windows. Intenté ejecutar el mismo script usando Node en el símbolo del sistema ... y hola ... funcionó ????

Acabo de encontrar el mismo error y no puedo encontrar una manera de detectarlo. Estoy construyendo un proxy de imagen, por lo que realmente no puedo controlar lo que devuelve el otro servidor. ¿Cómo puedo evitar que se cargue todo el servidor en producción?

Tuve el mismo problema, empezó a funcionar cuando cambio el "set" por "auth". Por ejemplo:

it('ERROR, Wrong GET request', (done)=>{
    request(server).get("/api/")
    .set('Authorization', 'Bearer ' + tokenKey)
    .then(res=>{
        expect(res.statusCode).to.equal(404);
        done()
    }).catch(err=>done(err))
})

RES DE LA CONSOLA: ERROR, Solicitud GET incorrecta:
TypeError [ERR_INVALID_CHAR]: carácter no válido en el contenido del encabezado ["Autorización"]

Después de cambiar el código a:

it('ERROR, Wrong GET request', (done)=>{
    request(server).get("/api/")
    .auth('Authorization', 'Bearer ' + tokenKey) //**<---here is the change**
    .then(res=>{
        expect(res.statusCode).to.equal(404);
        done()
    }).catch(err=>done(err))
})

CONSOLA RES: OKI; p

¿Fue útil esta página
0 / 5 - 0 calificaciones