2009-11-30 14 views
11

¿Realiza más (IE, FF, Safari, Chrome, Opera) múltiples solicitudes HTTP para un archivo PDF cuando visualiza el PDF en un navegador? Estoy trabajando en un problema que se integra con el software WebTrends Web Analytics, y las estadísticas en torno a los PDF parecen ser incorrectas. El soporte me dijo que debido a que WebTrends analiza los registros de acceso de los servidores web para determinar el tráfico, descargas, etc., tiene dificultades para determinar descargas precisas de PDF porque:
Cuando un usuario hace clic en un PDF y se abre en el navegador del usuario a través del Complemento del navegador Acrobat Reader, cada página se descarga de a una por vez: hace esto para conservar el ancho de banda, si un usuario solo ve las primeras 2 páginas de un PDF de 50 páginas, solo se descargan las 2 primeras páginas.¿La mayoría de los navegadores realizan varias solicitudes HTTP al mostrar un PDF desde el navegador?

Esto me suena sospechoso (¿cómo se podría hacer una solicitud HTTP para que solo sirva una porción de un archivo binario?) - He estado buscando en Google, pero no he encontrado nada que me hable de esto.

Voy a tratar de encontrar algún software de IE que me permita oler el tráfico HTTP mañana para ver si puedo observar este fenómeno.

Cualquier información/pensamientos son apreciados sin embargo.

+1

No es una respuesta como tal, pero http admite la descarga de partes de archivos a través del encabezado del rango de contenido. Tal vez PDF lo usa ... * encoge de hombros * – Will

+2

He encontrado Fiddler muy útil para ese tipo de identificación de paquetes IP. –

+0

Ver [RFC 2616, Sección 3.12] (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.12). –

Respuesta

13

Si su sitio devuelve un encabezado de respuesta HTTP como esto:

Accept-Ranges: bytes 

el lector PDF cerrará la conexión intitial después de leer sólo unos pocos KB del documento. Se solicita entonces las secciones del documento según sea necesario con el encabezado de solicitud rango, por ejemplo .:

Range: bytes=242107-244329, 8060-76128 

Un ejemplo de una dirección URL que hace esto es http://www.ovationguitars.com/img/OVmanual.pdf.

Si usted no devuelve la cabecera Accept-Ranges continuación, el documento PDF se descargará en una sola petición (por ejemplo http://manuals.info.apple.com/en/iphone_user_guide.pdf)

Se puede ver el comportamiento del lector de PDF en IE usando HttpWatch.

** Exención de responsabilidad: Esta respuesta fue publicada por Simtec limitada, los fabricantes de HttpWatch **

+0

¡Muy interesante gracias! Parece que esto es posible, sin embargo, después de una investigación más profunda (ver las HTTPRequests/Respsonses) no parece que el complemento Adobe Acrobat Reader para IE admita la creación de solicitudes de esta manera (y posiblemente tampoco la aplicación web que está sirviendo a los PDF) no he enviado ninguna solicitud sintética de los rangos de bytes) – empire29

+0

He comprobado el iphone_user_guide.pdf (https://manuals.info.apple.com/MANUALS/1000/MA1565/en_US/iphone_user_guide.pdf) en Chrome y recibo 2 solicitudes : El primero está bien. El segundo es cancelado. –

+0

Todavía veo este comportamiento hoy, y Fiddler muestra que no hay encabezados que acepten rangos. –

0

Lo que yo pienso es que no tiene problema alguno: su complemento no puede (y no debe) dividir archivos PDF en solicitudes.

Tengo una aplicación web que sirve archivos PDF a partir de una solicitud (una sola solicitud) y se muestra en un complemento. Muestra todo el PDF sin obtener más información.

Además, si está buscando un sniffer HTTP puede probar Fiddler. Lo encontré útil durante la depuración del sitio web.

+0

Lo comprobé en HTTPWatch usando IE (el navegador oficial "compatible" de la compañía) con el último complemento de Adobe Acrobat Reader y estaba procesando PDF completos. No vi nada en los encabezados sobre los rangos de bytes. – empire29

2

Para mí a partir de junio de 2016, Firefox y EI11 sólo hacer una llamada.

Chrome realiza dos llamadas si no hay un encabezado Content-Disposition. Cuando falta, Chrome hace dos GET, parece cancelar el segundo y muestra el PDF en el navegador. El servidor no sabe que el segundo se canceló y envía el PDF nuevamente.

Cuando este encabezado se envía desde el servidor, Chrome solo realiza una llamada y ejecuta o guarda el archivo.

Content-Disposition: attachment 

(También puede sugerir el nombre del archivo que se utilizará cuando el usuario guarda el archivo ...)

Content-Disposition: attachment; filename=test.pdf 
+1

Agregar este encabezado evita la segunda llamada, pero también hace que Chrome descargue el PDF como un archivo adjunto y no lo abra inmediatamente dentro del navegador. – kman

+0

Sí. Sigo pensando que es un error, pero esta es una forma de evitarlo. –

+2

Bueno, el problema es el complemento PDF de Chrome. Con Content-Disposition: attachment, el complemento de PDF no se utiliza. Es por eso que no hay error. Más detalles aquí: https://bugs.chromium.org/p/chromium/issues/detail?id=587709 –

0

En mis pruebas, las solicitudes dobles para un occours PDF en Chrome si tengo la extensión REST Console 4.0.2 habilitada. Al deshabilitar esta extensión, Chrome funciona como se esperaba (solo una solicitud).

Editar: La extensión Instapaper habilitada también hace que Chrome haga solicitudes dobles a PDF.

Cuestiones relacionadas