Chrome DevTools Protocol Fetch Domain - getResponseBody - aparentemente falla con HTTP redirecciones

Deseo recoger el cuerpo de una solicitud HTTP, incluso cuando la página redirige a otros lugares. Claramente, puedo utilizar mecanismos de dominio no-Fetch como Network.getResponseBody. Eso funciona bien para la página "final" en una cadena de redirecciones, pero no se puede utilizar para las páginas intermedias porque Chrome parece dejar el contenido cuando va al próximo objetivo de redirección.

Así que, implementé Fetch.enable( { patterns: [ { requestStage: Response } ] } ) (utilizando PHP, pero los detalles de eso son irrelevantes, como verá). No se devuelve ningún error de esta llamada de método. Después de hacer un Page.navigate, espero un Fetch.requestPaused evento que contiene miembros requestId, responseStatusCode y responseHeaders y luego enviar un Fetch.getResponseBody (utilizando el requestId de la Fetch.requestPaused) y la respuesta que obtengo depende de cuál fue la respuesta real a la página en sí misma. Así que, para un 200, tengo un cuerpo de respuesta (hurray), pero para un 30x (301, 302 etc), siempre recibo código de error -32000 con el mensaje "Can only get response body on requests captured after headers received". Ahora, emitir ese mensaje de error es inconsistente (en mi opinión) con el Fetch.requestPaused los datos del evento, incluso si Chrome DevTools Protocol (CDP) no estaba destinado a capturar los cuerpos de las páginas redireccionadas HTTP. Por cierto, las páginas con contenido activaron la redirección (a través de un elemento META o JavaScript) se capturan bien, supongo porque devuelven un código de estado de 200.

Así que, es el problema en la secuencia de llamadas que estoy siguiendo o en el mensaje de error devuelto por Fetch.getResponseBody y estoy asumiendo correctamente que CDP no estaba destinado a capturar los cuerpos de documentos en una cadena de redirección (aparte de la última, obviamente)?

Pregunta hecha hace 3 años, 4 meses, 28 días - Por bytebard


3 Respuestas:

  • Usted necesita continuar la solicitud en un 301/302 y dejar que el navegador lo siga (no hay cuerpo en una redireccion):

        if (
          params.responseStatusCode === 301 || params.responseStatusCode === 302
        ) {
          await this.#client.send('Fetch.continueRequest', {
            requestId,
          });
        } else {
          // get body here
          const responseCdp = await this.#client.send('Fetch.getResponseBody', {
            requestId,
          });
        
          await this.#client.send('Fetch.fulfillRequest', {
            requestId,
            responseCode: params.responseStatusCode,
            responseHeaders: params.responseHeaders,
            body: responseCdp.body,
          });
        }
    

    Respondida el Dec 17, 2020 a las 14:51 - por byteexplorer

    Votos positivos: 0 | Votos negativos: 0

  • El mensaje de error que estás recibiendo al intentar obtener el cuerpo de respuesta de una solicitud redirigida utilizando Fetch.getResponseBody ("Can only get response body on requests captured after headers received") indica que el cuerpo de la respuesta solo se puede obtener en solicitudes capturadas después de que se hayan recibido todos los encabezados de la respuesta.

    En el caso de redirecciones HTTP, cuando se produce una redirección, la respuesta original se considera finalizada una vez que se reciben los encabezados de la redirección. Por lo tanto, cuando intentas obtener el cuerpo de respuesta en una solicitud redirigida, es probable que recibas ese error porque estás intentando acceder al cuerpo de la respuesta antes de que se complete la captura de la misma.

    Una posible solución sería esperar a que se complete la redirección y la solicitud final se capture correctamente antes de intentar obtener el cuerpo de la respuesta. Puedes monitorear el evento Fetch.requestPaused y asegurarte de que estás intentando obtener el cuerpo de respuesta en la solicitud correcta, es decir, la solicitud final que contiene el cuerpo de la respuesta que deseas.

    En resumen, es importante tener en cuenta el momento en que intentas acceder al cuerpo de la respuesta en una cadena de redirecciones y asegurarte de hacerlo en el momento adecuado para evitar errores como el que estás experimentando.

    Respondida el Dec 18, 2020 a las 14:47 - por Gpt

    Votos positivos: 0 | Votos negativos: 0

  • Problema:

    Chrome DevTools Protocol Fetch Domain getResponseBody falla con redirecciones HTTP, devolviendo el código de error -32000 y el mensaje Can only get response body on requests captured after headers received.

    Causa:

    El protocolo DevTools de Chrome no está diseñado para capturar los cuerpos de respuesta de las páginas intermedias en una cadena de redirecciones HTTP. Solo captura el cuerpo de respuesta de la página final en la cadena de redirección.

    Solución:

    Hay dos enfoques para resolver este problema:

    1. Usa el dominio Network:

    Utiliza el método Network.getResponseBody para capturar el cuerpo de respuesta de la página final en la cadena de redirección. Esto funcionará para todas las redirecciones, incluidas las que se producen mediante elementos META o JavaScript.

    2. Monitorea los eventos Fetch:

    Habilita el dominio Fetch con { patterns: [ { requestStage: Response } ] }. Cuando se active el evento Fetch.requestPaused, registra el requestId. Para las solicitudes con un código de estado de 200, envía Fetch.getResponseBody usando el requestId.

    Nota: Este enfoque solo capturará los cuerpos de respuesta de las páginas con un código de estado de 200. No capturará los cuerpos de respuesta de las páginas intermedias en una cadena de redirección.

    Conclusión:*

    El mensaje de error que recibes es correcto. El protocolo DevTools de Chrome no está diseñado para capturar los cuerpos de respuesta de las páginas intermedias en una cadena de redirección. Puedes utilizar los enfoques alternativos mencionados anteriormente para capturar los cuerpos de respuesta que necesitas.

    Respondida el Dec 18, 2020 a las 14:55 - por Gemini

    Votos positivos: 0 | Votos negativos: 0