2009-11-30 8 views
11

La maggior parte (IE, FF, Safari, Chrome, Opera) crea più richieste HTTP per un file PDF quando si visualizza il PDF in un browser? Sto lavorando su un problema che si integra con il software WebTrends Web Analytics e le statistiche relative ai PDF sembrano errate. Il supporto mi ha detto che poiché WebTrends analizza i registri di accesso dei server Web per determinare il traffico, i download, ecc. Ha difficoltà a determinare i download accurati del PDF perché:
Quando un utente fa clic su un PDF e il PDF si apre nel browser dell'utente tramite il Plug-in del browser Acrobat Reader, ogni pagina viene scaricata una alla volta, per conservare la larghezza di banda, se un utente visualizza solo le prime 2 pagine di un PDF di 50 pagine, vengono scaricate solo le prime 2 pagine.La maggior parte dei browser effettua più richieste HTTP durante la visualizzazione di un PDF dal browser

Mi sembra strano (come potrebbe essere fatta una richiesta HTTP per pubblicare solo una parte di un file binario?) - Ho cercato su Google, ma non ho trovato nulla che parli di questo.

Cercherò di trovare qualche software IE che mi permetta di annusare il traffico HTTP domani per vedere se riesco a osservare questo fenomeno.

Tutte le informazioni/pensieri sono tuttavia apprezzate.

+1

Non è una risposta in quanto tale, ma http supporta il download di parti di file tramite l'intestazione gamma di contenuti. Forse PDF lo usa ... * alza le spalle * – Will

+2

Ho trovato che Fiddler è molto utile per lo sniffing dei pacchetti IP. –

+0

Vedere [RFC 2616, Sezione 3.12] (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.12). –

risposta

13

Se il sito restituisce un'intestazione di risposta HTTP in questo modo:

Accept-Ranges: bytes 

il lettore PDF chiuderà la connessione intitial dopo aver letto solo alcuni KB del documento. E 'quindi richiede sezioni del documento, come richiesto con l'intestazione della richiesta Range, ad es .:

Range: bytes=242107-244329, 8060-76128 

Un esempio di un URL che fa questo è http://www.ovationguitars.com/img/OVmanual.pdf.

Se non si restituisce il Accept-Ranges intestazione poi il documento PDF viene scaricato in una singola richiesta (ad esempio http://manuals.info.apple.com/en/iphone_user_guide.pdf)

È possibile vedere il comportamento del lettore PDF in IE utilizzando HttpWatch.

** Disclaimer: Questa risposta è stato pubblicato da Simtec Limited, i creatori di HttpWatch **

+0

Molto interessante grazie! Sembra quindi possibile, tuttavia dopo ulteriori indagini (guardando le richieste HTTP/Risposte) non sembra che il plug-in Adobe Acrobat Reader per IE supporti la creazione di richieste in questo modo (e forse nemmeno l'applicazione Web che serve i PDF, sebbene non ho inviato alcuna richiesta sintetica per gli intervalli di byte) – empire29

+0

Ho controllato iphone_user_guide.pdf (https://manuals.info.apple.com/MANUALS/1000/MA1565/en_US/iphone_user_guide.pdf) in Chrome e ho ricevuto 2 richieste : Il primo è ok. Il secondo è annullato. –

+0

Sto ancora vedendo questo comportamento oggi, e Fiddler mostra che non ci sono intestazioni "accettabili". –

0

Il mio pensiero è che tu sia preciso: il tuo plug-in non può (e non dovrebbe) dividere i PDF in richieste.

Ho un'applicazione Web che serve file PDF da una richiesta (una singola richiesta) e visualizza in un plug-in. Visualizza l'intero PDF senza ottenere ulteriori informazioni.

Inoltre, se si sta cercando uno sniffer HTTP, è possibile provare Fiddler. Ho trovato questo utile durante il debug del sito web.

+0

L'ho verificato in HTTPWatch usando IE (il browser ufficiale "supportato" dell'azienda) con l'ultimo plug-in per lettore Adobe Acrobat e stava tirando giù interi PDF. Non ho visto nulla nelle intestazioni sugli intervalli di byte. – empire29

2

Per me a partire da giugno 2016, Firefox e IE11 solo fare una chiamata.

Chrome effettua due chiamate se non è presente l'intestazione Content-Disposition. Quando manca, Chrome fa due GET, sembra cancellare il secondo e mostra il PDF nel browser. Il server non sa che il secondo è stato cancellato e invia di nuovo il PDF.

Quando questa intestazione viene inviata dal server, Chrome effettua una sola chiamata e avvia o salva il file.

Content-Disposition: attachment 

(Si può anche suggerire il nome del file da utilizzare quando l'utente salva il file ...)

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

L'aggiunta di questa intestazione impedisce la seconda chiamata, ma fa sì che Chrome scarichi il PDF come un allegato e non lo apra immediatamente all'interno del browser. – kman

+0

Sì. Continuo a pensare che sia un bug, ma questo è un modo per aggirarlo. –

+2

Bene, il problema è il plug-in PDF di Chrome. Con Content-Disposition: allegato il plug-in PDF non viene utilizzato. Questo è il motivo per cui non vi è alcun errore. Maggiori dettagli qui: https://bugs.chromium.org/p/chromium/issues/detail?id=587709 –

0

Nel mio test, doppie richieste di un PDF in Chrome occours se ho l'estensione REST Console 4.0.2 abilitata. Disattivando questa estensione, Chrome funziona come previsto (solo una richiesta).

Modifica: l'estensione di Instapaper abilitata fa sì che Chrome esegua doppie richieste in PDF.

Problemi correlati