[PHP] pdf downloaden via php gaat soms mis in IE

[Anoniem: 79852]

Hallo,

Ik heb het volgende script om pdf's te kunnen downloaden om het aantal downloads te kunnen tellen.
Dat werkt goed in Google Chrome, maar niet altijd in IE 8

PHP:

$fs=filesize($path.$file);
$handle=fopen($path.$file,"rb");
$data=fread($handle,$fs);
fclose($handle);

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // some day in the past (te maken met caching) 
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); //te maken met caching
header('Cache-Control: must-revalidate, post-check=0, pre-check=0'); 
header('Content-Description: File Transfer');           
header("Content-Type: application/octet-stream");           
header('Content-Disposition: attachment; filename='.$file); 
header('Content-Transfer-Encoding: binary'); 
header('Content-Length: '.strlen($data));
echo($data);

Soms werkt de download wel (283kb) en opent de PDF normaal, soms krijg ik maar 243kb door en krijg ik de melding dat de PDF beschadigd is. Ik heb al 100 verschillende combinaties van headers (ook uit andere topics) gebruikt: content-type als application/pdf, als application/force-download, als application/octet-stream.
Content-length zowel met strlen($data) als met filesize() geprobeerd.

Memory limits aangepast, execution time aangepast, fopen($file,"r") ipv "rb"

Als ik de gelezen data opnieuw wegschrijf op de server als een nieuwe pdf en die met ftp download, dan gaat het wel goed en het aantal uitgelezen bytes ($fs en strlen($data)) klopt ook, terwijl de download nog mis gaat....

Heeft iemand een oplossing? alvast bedankt!

[Thomasje]

Bevat je file name spaties? (urlencode() gebruiken)

Je zou i.p.v. fopen, fread, fclose gewoon readfile() kunnen gebruiken.

[Anoniem: 79852]

filename bevat geen spaties of rare tekens.

ook al readfile geprobeerd.

en ook output buffering gebruikt, maakt allemaal niet uit.

tevens ook de foute pdfs ook gecontroleerd op php errors en warnings, maar die staan er niet in.

[Anoniem: 327097]

Kun je denk ik niks tegen doen, is tog ook vaker dat als je bijvoorbeeld een .pdf download dat je dan de source code krijgt te zien om een internetpagina

[Anoniem: 79852]

ja dan is er al data naar de browser verzonden, maar dat is niet het geval, dat controleer ik alvorens ik

PHP:

echo $data

doe, met

PHP:

 if(headers_sent())

[ Voor 5% gewijzigd door Anoniem: 79852 op 30-05-2010 10:53 ]

[Sebazzz]

Je zou eventueel nog in het serverlog kunnen kijken als je daar toegang tot hebt.

[Anoniem: 79852]

kan ik niks speciaals in vinden.

heb ook error_reporting op E_ALL gezet om te zien of er iets mis ging, maar ook niet het geval...

[Sebazzz]

Stel eens in dat het script niet afbreekt als de client de verbinding verbreekt en/of stel een Keep-Alive in.

[Anoniem: 79852]

heb het ook geprobeerd met ignore_user_abort(1);
en header("Connection: Keep-Alive");

maar nog geen verschil...

[simon]

Als je alleen de download telt, dan stuur je hem met header ("Location: http://aard.vark/file.pdf"); gewoon door? Hoe je PHP ook niet je file te laten verwerken. Tel je gewoon de click.

[ Voor 6% gewijzigd door simon op 30-05-2010 11:26 ]

[Sebazzz]

In dat geval kan je beter de testset verbreden, werkt het in IE7 mode, werkt het in Firefox, werkt het met programma's ala WGET, enzovoort.
Je kan eventueel ook Wireshark in te zetten en die laten filteren op het HTTP niveau om te kijken wat er gebeurt.

simon schreef op zondag 30 mei 2010 @ 11:26:
Als je alleen de download telt, dan stuur je hem met header ("Location: http://aard.vark/file.pdf"); gewoon door? Hoe je PHP ook niet je file te laten verwerken. Tel je gewoon de click.

Je wilt niet altijd de originele locatie van het bestand exposen, maar wat ik uit de TS opmaak kan dit een optie zijn.

[ Voor 44% gewijzigd door Sebazzz op 30-05-2010 11:27 ]

[DukeBox]

Ik heb wel eens vreemde dingen meegemaakt met de expire header. Als je deze nu eens gewoon timestamp in de toekomst meegeeft zoals het hoort (desnoods van 1 min). of weglaat ? Bijv. SQUID proxy negeerd hoe dan ook ongeldige expire headers.

[ Voor 19% gewijzigd door DukeBox op 30-05-2010 11:40 ]

[Anoniem: 79852]

Het is inderdaad de bedoeling om bestandslocatie te verbergen.

Wireshark ken ik niet, ga ik zo even googlen. Expire header zal ik ook nog eens proberen in toekomst. Weglaten van die header geeft iig geen verschil.

[Xander]

Exact dit probleem heb ik ook eens gehad, alleen met IE en inderdaad met te kleine files als resultaat.

Ik durf niet te zeggen dat de oorzaak bij mij bij de gzip-compressie lag, maar die uitschakelen heeft het in ieder geval wel opgelost.

Dus, kun je eens kijken of dat aan staat? Uitschakelen kon bij mij met een .htaccess file:

code:

SetEnv no-gzip dont-vary

[Anoniem: 79852]

Xander schreef op zondag 30 mei 2010 @ 11:56:
Exact dit probleem heb ik ook eens gehad, alleen met IE en inderdaad met te kleine files als resultaat.

Ik durf niet te zeggen dat de oorzaak bij mij bij de gzip-compressie lag, maar die uitschakelen heeft het in ieder geval wel opgelost.

Dus, kun je eens kijken of dat aan staat? Uitschakelen kon bij mij met een .htaccess file:

code:

SetEnv no-gzip dont-vary

super! dank je!
dit was idd de oplossing...

[HuHu]

Ik weet niet zeker of je op de huidige manier de content-length wel betrouwbaar kunt berekenen. Het geheel kan ook makkelijker, middels de fpassthru functie.

Voorbeeld:

PHP:

<?php
// open the file in a binary mode
$name = './img/ok.png';
$fp = fopen($name, 'rb');

// send the right headers
header("Content-Type: image/png");
header("Content-Length: " . filesize($name));

// dump the picture and stop the script
fpassthru($fp);
exit;
?>

Voeg nog even je eigen headers er aan toe en het zou moeten werken.

[Xander]

HuHu schreef op zondag 30 mei 2010 @ 13:30:
Ik weet niet zeker of je op de huidige manier de content-length wel betrouwbaar kunt berekenen. Het geheel kan ook makkelijker, middels de fpassthru functie.

Dan kun je net zo goed readfile() gebruiken, toch? Dat staat zelfs in de documentatie van fpassthru:

quote: http://php.net/fpassthru

If you just want to dump the contents of a file to the output buffer, without first modifying it or seeking to a particular offset, you may want to use the readfile(), which saves you the fopen() call.

Anoniem: 79852 schreef op zondag 30 mei 2010 @ 13:29:
[...]


super! dank je!
dit was idd de oplossing...

Mooi.

Maar ik snap niet waarom het fout zou gaan mét gzip-compressie, misschien dat iemand daar nog een licht op kan werpen? Wellicht gaat gzip-compressie in combinatie met het meegeven van de Content-Length fout?

[Anoniem: 79852]

bij de comments van de readfile manual staat deze oplossing ook, met een kleine toelichting. (eerder niks meegedaan omdat ik zelf geen compressie toepaste...)
waarschijnlijk raakt IE in de was omdat er een C.Length wordt doorgegeven (uncompressed) die dus afwijkt van de werkelijke lengte van de gzip compressie.
Ik denk dat IE dan de lengte van de gzip compressie overneemt en daardoor een stuk van de uitgepakte file afsnijdt....

Xander schreef op zondag 30 mei 2010 @ 13:44:
[...]


Dan kun je net zo goed readfile() gebruiken, toch? Dat staat zelfs in de documentatie van fpassthru:


[...]


[...]


Mooi.

Maar ik snap niet waarom het fout zou gaan mét gzip-compressie, misschien dat iemand daar nog een licht op kan werpen? Wellicht gaat gzip-compressie in combinatie met het meegeven van de Content-Length fout?

[Xander]

Anoniem: 79852 schreef op zondag 30 mei 2010 @ 14:10:
waarschijnlijk raakt IE in de was omdat er een C.Length wordt doorgegeven (uncompressed) die dus afwijkt van de werkelijke lengte van de gzip compressie.

Wie weet. Maar de Content-Length is dan dus groter dan de daadwerkelijke data, het lijkt me juist niet dat hij de download dan te vroeg afkapt.

Ik denk dat IE dan de lengte van de gzip compressie overneemt en daardoor een stuk van de uitgepakte file afsnijdt....

En dat maar af en toe?

Achja, IE is vaag, da's op zich niets nieuws... Maar het klinkt toch wel vergezocht.

[NMe]

Anoniem: 327097 schreef op zondag 30 mei 2010 @ 10:49:
Kun je denk ik niks tegen doen, is tog ook vaker dat als je bijvoorbeeld een .pdf download dat je dan de source code krijgt te zien om een internetpagina

Onzin. Als je je server en je script goed heb geconfigureerd zou dat niet mogen gebeuren.

Xander schreef op zondag 30 mei 2010 @ 11:56:
Exact dit probleem heb ik ook eens gehad, alleen met IE en inderdaad met te kleine files als resultaat.

Ik durf niet te zeggen dat de oorzaak bij mij bij de gzip-compressie lag, maar die uitschakelen heeft het in ieder geval wel opgelost.

Dus, kun je eens kijken of dat aan staat? Uitschakelen kon bij mij met een .htaccess file:

code:

SetEnv no-gzip dont-vary

Dat zou je dan wel alleen willen doen bij relevante bestanden, dus die .htaccess zou ik in zijn eigen mapje zetten met de file die deze PDF's serveert. 't Is zo jammer om gzip op een complete webroot uit te zetten alleen omdat het een scriptje b0rkt.

[ Voor 72% gewijzigd door NMe op 30-05-2010 14:39 ]

[Anoniem: 79852]

NMe schreef op zondag 30 mei 2010 @ 14:36:
Dat zou je dan wel alleen willen doen bij relevante bestanden, dus die .htaccess zou ik in zijn eigen mapje zetten met de file die deze PDF's serveert. 't Is zo jammer om gzip op een complete webroot uit te zetten alleen omdat het een scriptje b0rkt.

daar staat die ook in