[PHP] PDF download via header currupt, Sessie of Buffering ?

[Verwijderd]

Ik heb tot redelijk laat in de nacht een probleem geprobeerd te analyseren dat ik maar niet kan vinden.

Ik heb een pagina, daarin kan ik via een header een bestand downloaden, een PDF in dit geval:

PHP:

header('Content-Type: application/pdf');
header("Content-Disposition: attachment; filename=" . $file_name);
header("Content-Length: " . (string)(filesize($dir.$file_name)));
@readfile($dir.$file_name);
exit;
break;

Dit werkt prima en zonder problemen.

Nu heb ik om de pagina een een login script heen gebouwd, werkt ook prima.

Ik heb voor dit login script Output Buffering moeten gebruiken omdat ik namelijk wat headers moet kunnen versturen, tevens maak ik gebruik van sessies om iedere pagina natuurlijk te verifieren, ook de pagina waar bovenstaande code in staat.

Nu werkt de download opzich goed, echter komt mijn bestand altijd corrupt aan, het komt er eigenlijk op neer dat het bestand als HTML verstuurd wordt.

Als ik "inline" in de header gebruik dan zie ik allemaal PDF data, als ik "attachment" gebruik krijg ik een corrupte file binnen met verschillende meldingen, waaronder deze:

"file does not begin with %PDF-"


Ik begin mij dus sterk af te vragen hoe dit kan, ik verdenk een combinatie van Sessies en Output Buffering ?

Ik heb er over gedacht om dit stuk download code in een aparte file te zetten en deze aan te roepen via mijn download link. Dit is alleen een beetje omslachtig, want bovenstaand zou gewoon moeten werken, wat het voorheen ook zonder mijn "Login creaties" wel deed.

Wat zou een dergelijke corruptie kunnen beinvloeden ?

[storeman]

Verstuur je ook caching headers? Ik heb hier problemen mee ondervonden. Het volgende kon wel eens de fout veroorzaken:

PHP:

header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past

Overigens heeft IE er ook nog wel eens last van om de verkeerde headers te onthouden, ook na een harde refresh. Gewoon IE even afsluiten en opnieuw opstarten, dan gaat het wel goed. (echter zie je dan gewoon de PDF source, dat lijkt niet jou geval te zijn)

[ Voor 31% gewijzigd door storeman op 10-03-2008 12:07 . Reden: extra info ]

[Voutloos]

Verwijderd schreef op maandag 10 maart 2008 @ 11:59:
Als ik "inline" in de header gebruik dan zie ik allemaal PDF data, als ik "attachment" gebruik krijg ik een corrupte file binnen met verschillende meldingen, waaronder deze:

"file does not begin with %PDF-"

En is dat ook zo? Is het pdf bestand zelf goed?
Indien antwoord op beide vragen ja is, dan heb je gewoon wél output ervoor zitten. Om te ontdekken waar de output vandaan komt, kan je gewoon op dat exacte punt een header() call zetten zodat je de 'output started at ...' error krijgt.

Als je dan nog steeds overtuigd bent dat je nergens iets output, moeten we de huidige code te zien krijgen.

[MueR]

Zet eens ob_clean(); voor je headers.

[Verwijderd]

storeman schreef op maandag 10 maart 2008 @ 12:03:
Verstuur je ook caching headers? Ik heb hier problemen mee ondervonden. Het volgende kon wel eens de fout veroorzaken:

PHP:

header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past

Overigens heeft IE er ook nog wel eens last van om de verkeerde headers te onthouden, ook na een harde refresh. Gewoon IE even afsluiten en opnieuw opstarten, dan gaat het wel goed. (echter zie je dan gewoon de PDF source, dat lijkt niet jou geval te zijn)

Als ik je geod begrijp ik heb ik hetgeen dat jij bovenstaand post niet in mijn headers staan, en zou dus ook niet moeten ?

Als dat er dus niet zou moeten staan moet ik verder zoeken naar een mogelijk probleem.

Herstarten heeft geen zin helaas. Als ik het in mijn virtuele windows machine probeer te downloaden krijg ik gewoon een melding dat het bestand currupt is, echter als ik bestanden in Linux wil openen met Document viewer krijg ik de volgende melding:

MIME-type ‘text/html’ niet bekend

Ik heb dus het idee dat door mijn output buffering de header van de pagina zelf (HTML) gebruikt wordt inplaats van de header om te downloaden.

Voutloos schreef op maandag 10 maart 2008 @ 12:21:
[...]
En is dat ook zo? Is het pdf bestand zelf goed?
Indien antwoord op beide vragen ja is, dan heb je gewoon wél output ervoor zitten. Om te ontdekken waar de output vandaan komt, kan je gewoon op dat exacte punt een header() call zetten zodat je de 'output started at ...' error krijgt.

Als je dan nog steeds overtuigd bent dat je nergens iets output, moeten we de huidige code te zien krijgen.

Ja, PDF is prima in orde.

Zoals ik in mijn TS vertel werkt mijn script zonder mijn login and output buffering creatie prima, ik ben dus bang dat het ergens in die output buffering zit, of zou ik een sessiestart moeten hebben "in" die download ?

Bestandsformaat is ook goed, filenaam ook in de corrupte download.

edit:


@MueR: Dan ben ik een deel van mijn pagina kwijt... wellicht een redesign nodig

[storeman]

Probeer eens die headers die ik in mijn vorige post had staan, maar dan met een paar minuten in de toekomst en caching aan, wellicht dat dat scheelt (misschien worden die header bij je login meegestuurd).

[Verwijderd]

storeman schreef op maandag 10 maart 2008 @ 12:54:
Probeer eens die headers die ik in mijn vorige post had staan, maar dan met een paar minuten in de toekomst en caching aan, wellicht dat dat scheelt (misschien worden die header bij je login meegestuurd).

Helaas, geen werkende optie.

Ik denk ook aan redesign van dit stuk, maar opzich zou output buffering geen probleem op mogen leveren, tenminsite... Je zou het "uit" moeten kunnen schakelen voor een dergelijk stuk.

[Voutloos]

Je wil gewoon geen output voor en na het outputten van de pdf. Dus moet je of die output elimineren, of de output buffer cleanen. Klaar.

Verwijderd schreef op maandag 10 maart 2008 @ 12:45:
@MueR: Dan ben ik een deel van mijn pagina kwijt... wellicht een redesign nodig

Que? Je pagina heeft niets te maken met die pdf download request. Zorg er iig voor dat je alle output voor het outputten van de pdf weg knikkert.

Overigens zijn output problemen als deze, alsmede de welbekende fout bij het zetten van een header nadat output al gestart is altijd eenvoudig op te lossen. Wat opvalt is dat in 9 vd 10 topics over dit probleem de topicstarter bij hoog en laag alle verkeerde output ontkent en aan het einde van het topic toegeeft "dat er toch wat output was".

Je hebt output, want je bent niet voor niets de output buffer gaan gebruiken. Dan moet je wel die buffer op de goede manier leegmaken (clean != flush), anders komt het er alsnog uit.

[ Voor 9% gewijzigd door Voutloos op 10-03-2008 13:04 ]

[Janoz]

Verwijderd schreef op maandag 10 maart 2008 @ 11:59:

"file does not begin with %PDF-"

Bekijk eens wat de inhoud van het gedownloade bestand is. Zeer waarschijnlijk staat de html van je site nog voorin het bestand.....

[MueR]

Janoz schreef op maandag 10 maart 2008 @ 13:11:
[...]

Bekijk eens wat de inhoud van het gedownloade bestand is. Zeer waarschijnlijk staat de html van je site nog voorin het bestand.....

Vandaar dat ik ook zei, zet ob_clean() voor je headers

@TS
Je bent HTML in een PDF aan het proppen. Ik snap niet waar je heen wil met dit verhaal, maar als je een PDF wil laten downloaden, moet je daar een los script voor maken. Daar hoort geen HTML in. Niks, nog geen witruimte die niet in het bestand zit hoor je te outputten.

[ Voor 32% gewijzigd door MueR op 10-03-2008 13:27 ]

[Voutloos]

Vandaar dat ik ook zei, "En is dat ook zo?" als reactie op die foutmelding.
Die vraag is enkel goed te beantwoorden door naar de response te kijken, wat tevens ook een heel logische actie is als je zo'n melding ziet.

[curry684]

Verander je headers eens tijdelijk in:

PHP:

header('Content-Type: text/plain');
header("Content-Disposition: inline");
header("Content-Length: " . (string)(filesize($dir.$file_name)));

En ga je daarna nog eens afvragen of je snapt hoe HTTP werkt.

[Verwijderd]

Janoz schreef op maandag 10 maart 2008 @ 13:11:
[...]

Bekijk eens wat de inhoud van het gedownloade bestand is. Zeer waarschijnlijk staat de html van je site nog voorin het bestand.....

Klopt, een groot gedeelte.

Hierna komt gewoon de %PDF-1.3

[curry684]

Verwijderd schreef op maandag 10 maart 2008 @ 13:28:
[...]

Klopt, een groot gedeelte.

Hierna komt gewoon de %PDF-1.3

En Adobe Reader moet maar op de gok gaan raden dat die HTML junk is omdat jij je site slecht hebt opgezet en een ctrl-F op 'pdf' doen of zo?

[MueR]

Gek he, dat je PDF corrupt is. HTML != PDF, dus dat snapt je PDF lezert niet.

[Voutloos]

Voutloos schreef op maandag 10 maart 2008 @ 13:00:
Wat opvalt is dat in 9 vd 10 topics over dit probleem de topicstarter bij hoog en laag alle verkeerde output ontkent en aan het einde van het topic toegeeft "dat er toch wat output was".

Verwijderd schreef op maandag 10 maart 2008 @ 13:28:
Klopt, een groot gedeelte.

[Verwijderd]

curry684 schreef op maandag 10 maart 2008 @ 13:29:
[...]

En Adobe Reader moet maar op de gok gaan raden dat die HTML junk is omdat jij je site slecht hebt opgezet en een ctrl-F op 'pdf' doen of zo?

Dat zeg ik toch niet ?


Ik probeer het juist tegen te gaan

Ik vind je mening wat kort door de bocht, over slecht trouwens.

Ik geeft zelf al aan dat er wellicht een redesign plaats moet vinden hier of daar, jij bent wel perfect ?

En ik ontken niets, ik kwam daar om 5 uur 's nachts even niet meer uit... lijkt me logisch

Ik zal eens even kijken hoe ik dit het beste om kan bouwen, ik weet in ieder geval waar het probleem zich ongeveer bevindt.

[ Voor 17% gewijzigd door Verwijderd op 10-03-2008 13:45 ]

[MueR]

Een file pushing script hoort geen HTML te bevatten. Vanuit HTML pagina's hoor je er naar te linken. Denk daar maar eens aan bij een redesign.

[curry684]

Verwijderd schreef op maandag 10 maart 2008 @ 13:43:
[...]

Dat zeg ik toch niet ?

Nou je hebt al meer dan 10 posts lang geen idee wat er schadelijk aan is aan HTML-data in je PDF-output te mixen, of als je dat wel hebt weet je het verdomd goed te maskeren. Vandaar ook dat ik al fijntjes opmerkte dat het wellicht loont om je een beetje te verdiepen in hoe HTTP werkt.

Ik vind je mening wat kort door de bocht, over slecht trouwens.

Sorry, een site die HTML gaat renderen alvorens te besluiten dat er toch PDF-output moet komen is slecht opgezet, dat is een onomstotelijk feit waar ruime noch korte bochten aan te pas komen.

Ik zal eens even kijken hoe ik dit het beste om kan bouwen, ik weet in ieder geval waar het probleem zich ongeveer bevindt.

'ongeveer'....?

Mag ik uit pure interesse vragen hoe je dit nu op gaat lossen?

_{en ja de nette en correcte oplossing is al een paar schermen hierboven gegeven}

[Verwijderd]

MueR schreef op maandag 10 maart 2008 @ 13:48:
Een file pushing script hoort geen HTML te bevatten. Vanuit HTML pagina's hoor je er naar te linken. Denk daar maar eens aan bij een redesign.

Dit was al iets wat me niet lekker zat in mijn script, echter na wat zoekwerk online vond ik andere toepassingen in script niet echt veel beter.

Ik kom er wel uit