[PHP] Download headers

[Verwijderd]

Ik wil een bestand downloaden vanuit een php bestand.

Deze code heb ik op dit moment maar het probleem is dat deze niet download maar alles in vreemde tekens op het scherm laat zien.

PHP:

$file = "blaat.zip"; 
if ($fp=@fopen($file,"r")) {   
    header("Content-Type: application/download\n");  
    header("Content-Disposition: attachment; filename=" . $file);   
    header("Pragma: no-cache");   
    header("Expires: 0");   
    @fpassthru($fp);   
}

wat is er verkeerd aan deze code.

Ik test het echter wel op een localhost ik weet niet of dat het probleem misschien is.

[RupS]

Begin met het weghalen van de @
Daarmee onderdruk je errormeldingen, dan wordt het sowieso lastig om te kijken wat er mis gaat

en zet bovenaan je script:
error_reporting(E_ALL);

[ Voor 18% gewijzigd door RupS op 18-07-2003 15:54 ]

[Verwijderd]

Resultaat is precies hetzelfde, en ja ik wist waarvoor het diende.

[Bosmonster]

application/download?

was dat voor content-type?

(geen ZIP in ieder geval)..

[ Voor 22% gewijzigd door Bosmonster op 18-07-2003 15:58 ]

[RRX]

kan je niet gewoon de echte content/type doorgeven wat het is?
bijv. image/jpeg oid

[Soultaker]

"application/download" is NIET een geldige MIME-type. Vandaar dat sommige browsers (o.a. Internet Explorer voor Windows) 'm dan gaan downloaden, maar veel andere browsers (o.a. alle versies van Mozilla) geven 'm dan als plain-text weer (waarschijnlijk jouw "vreemde tekens"?). Probeer daar dus eens "application/octet-stream" van te maken, zoals het hoort.

[HunterPro]

bosmonster: als je een type meegeeft dat de browser niet kent zou ie het moeten gaan openen?

Het is idd wel netter om een database met filetypes bij te houden met daarin de application-types. Dan dus de extensie van die file uitlezen, matchen tegen de database en als het juiste type uitgeven. Dan moet het online viewen van PDF's op deze manier zelfs geen probleem zijn.

[Verwijderd]

Probeer dit anders es

code:

if ($_SERVER['HTTP_USER_AGENT'] == 'MSIE') {
  header('Content-Disposition: inline; filename="filename.ext"');
  header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
  header('Pragma: public');
} else {
  header('Content-Disposition: attachment; filename="filename.ext"');
  header('Pragma: no-cache');
}

[Verwijderd]

keer de bovenste 2 headers eens om en haal attachment; ertussenuit
en inderdaad download vervangen voor octet-stream

------
is het octet-stream of octetstream ik gebruik hem nl altijd zonder streepje

[ Voor 52% gewijzigd door Verwijderd op 18-07-2003 16:07 ]

[Verwijderd]

Ik krijg nu met deze code wel een download window alleen wil hij het script zelf downloaden ipv de blaat.zip

PHP:

<?
  if ($_SERVER['HTTP_USER_AGENT'] == 'MSIE') {
  header('Content-Disposition: inline; filename="blaat.zip"');
  header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
  header('Pragma: public');
} else {
  header('Content-Disposition: attachment; filename="blaat.zip"');
  header('Pragma: no-cache');
}
?>

[ Voor 15% gewijzigd door Verwijderd op 18-07-2003 16:09 ]

[JeRa]

Je moet ook wel het bestand doorgeven.

Alleen headers doorgeven gaat niet.

[Soultaker]

Verwijderd schreef op 18 July 2003 @ 16:03:
is het octet-stream of octetstream ik gebruik hem nl altijd zonder streepje

Het is application/octet-stream.

[E-Vix]

Dit volgende script het ik al tijden in gebruik, en het werk perfect.

PHP:

<?
$mime = "application/octet-stream"
$filesize = filesize("$file");

header("Content-type: $mime");
header ("Content-Length: $filesize");
header("Content-Disposition: attachment; filename=$file");

$download = fopen("$file","r");    
fpassthru($download);     
fclose($download); 
?>

[cybermans]

het enige nadeel dat ik er mee heb van app/octet-stream als ik eht weer upload is: als je de mime type uitleest is het ook app/octet-stream en niet de goede. Dit is best wel klote om het zo maar te noemen. Want als je files daarop wil identifyen heb je een probleem

[Soultaker]

cybermans schreef op 18 July 2003 @ 19:08:
het enige nadeel dat ik er mee heb van app/octet-stream als ik eht weer upload is: als je de mime type uitleest is het ook app/octet-stream en niet de goede. Dit is best wel klote om het zo maar te noemen. Want als je files daarop wil identifyen heb je een probleem

Erm ja, maar als dat de bedoeling is, waarom geef je dan application/octet-stream aan om mee te beginnen? Zet dan gelijk je content-type goed en laat mensen die bestanden willen downloaden dat zelf doen.

[alienfruit]

E-Vix schreef op 18 juli 2003 @ 18:57:
(heleboel code waar de schaar doorheen is gezet)

Echt? Ik heb net zoiets gebruikt, en ik kreeg toch nog soms dat hij .php nog achter het bestandsnaam plakte. Dus heb ik uiteindelijk maar gewoon direct links gebruikt.

Hmm. Toch nog niet helemaal wakker
Jij gebruikt attachment nog bij Content-Disposition wat is het verschil met en zonder? (dacht namelijk dat alleen voor emails was)

[ Voor 23% gewijzigd door alienfruit op 18-07-2003 20:01 ]

[cybermans]

als je niet wil dat iedereen rechtermuis moet gebruiken doe ik die octet stream want anders krijg je het in je browser geopent en dat kan ik me gebuikers ook niet maken.

[E-Vix]

alienfruit schreef op 18 juli 2003 @ 19:58:
[...]

Hmm. Toch nog niet helemaal wakker
Jij gebruikt attachment nog bij Content-Disposition wat is het verschil met en zonder? (dacht namelijk dat alleen voor emails was)

Attachement gebruik je voor als je het bestand wilt laten downloaden van de server. Je kunt ook kiezen voor inline, maar dan krijg je de data van het te downloaden bestand in je browser te zien.

[alienfruit]

Hmm. Okay, binnenkort eens proberen. Thanks. Weer wat geleerd.

[Verwijderd]

E-Vix schreef op 18 July 2003 @ 18:57:
Dit volgende script het ik al tijden in gebruik, en het werk perfect.

PHP:

<?
$mime = "application/octet-stream"
$filesize = filesize("$file");

header("Content-type: $mime");
header ("Content-Length: $filesize");
header("Content-Disposition: attachment; filename=$file");

$download = fopen("$file","r");    
fpassthru($download);     
fclose($download); 
?>

Maar er zit wel een foutje in:

The file is closed when fpassthru() is done reading it (leaving handle useless).
_{Bron: PHP.net}

Geen fclose() gebruiken dus

=edit=
En waarom gebruik je überhaupt "$file" ipv $file?

[ Voor 12% gewijzigd door Verwijderd op 18-07-2003 22:07 ]

[stekkel]

Dit doen we in Squirrelmail (GNU GPL):

PHP:

 $isIE = $isIE6 = 0;
 // interne SquirrelMail functie om te werken met super globals op verschillende php versies
 // $HTTP_USER_AGENT = $_SERVER['HTTP_USER_AGENT']; zou moeten werken.
 sqgetGlobalVar('HTTP_USER_AGENT', $HTTP_USER_AGENT, SQ_SERVER);

 if (strstr($HTTP_USER_AGENT, 'compatible; MSIE ') !== false &&
    strstr($HTTP_USER_AGENT, 'Opera') === false) {
    $isIE = 1;
 }

 if (strstr($HTTP_USER_AGENT, 'compatible; MSIE 6') !== false &&
    strstr($HTTP_USER_AGENT, 'Opera') === false) {
    $isIE6 = 1;
 }


 if ($isIE && !$isIE6) {
     header("Content-Disposition: inline; filename=$filename");
     header("Content-Type: application/download; name=\"$filename\"");
 } else {
     header("Content-Disposition: attachment; filename=\"$filename\"");
     header("Content-Type: application/octet-stream; name=\"$filename\"");
 }

// hierna mag je data spugen

En dat werkt al jaren voor miljoenen gebruikers

Zoals je ziet het hangt er nogal vanaf met wat voor browsers je te maken hebt. alles voor IE6 en van het type IE (dus IE 5.5, IE5, IE4) gebruikt application/download als content-type. De rest gedraagd zich zoals het moet en kan met application/octet-stream uit de voeten.

[ Voor 64% gewijzigd door stekkel op 19-07-2003 12:43 . Reden: vage zin verduidelijken ]

[Soultaker]

stekkel schreef op 19 July 2003 @ 00:43:
Zoals je ziet het hangt er nogal vanaf met wat voor browsers je te maken hebt. alles voor IE6 en IE gebruikt application/download als content-type.

Ten eerste is je opmerking hier gewoon fout: voor IE behalve IE6 gebruik je application/download (niet en!).

Verder gebruikt IE helemaal geen application/download, maar heeft 'ie toevallig een default actie voor types die 'ie niet kent, die jou nu toevallig goed uitkomt. Je had net zo goed "snorp/flotz" neer kunnen zetten, dan was het tenminste duidelijk dat dat type nergens op slaat (terwijl je nu suggereert dat application/download een zinnige betekenis heeft). Ook wel erg lomp dat je nu dubbele code moet gaan schrijven: eentje waarin je het goed doet en eentje waarin je het doet zoals het voor MSIE moet.

Wat doet MSIE5 eigenlijk fout bij application/octet-stream? Volgens mij moet dat ook gewoon werken. Waar baseer je je alternatief nu op? Ik mag toch hopen dat het niet gewoon giswerk/kopieerwerk is?

offtopic:
Verder vind ik je PHP code erg lelijk; fout geindent, nutteloze initialisatie en nutteloze if-statements. Initialiseer je variabelen gewoon in één keer goed!

[ Voor 36% gewijzigd door Soultaker op 19-07-2003 02:11 ]

[stekkel]

Soultaker schreef op 19 juli 2003 @ 02:05:
[...]

Ten eerste is je opmerking hier gewoon fout: voor IE behalve IE6 gebruik je application/download (niet en!).

zal het fixen, was niet zo scherp meer.

Verder gebruikt IE helemaal geen application/download, maar heeft 'ie toevallig een default actie voor types die 'ie niet kent, die jou nu toevallig goed uitkomt. Je had net zo goed "snorp/flotz" neer kunnen zetten, dan was het tenminste duidelijk dat dat type nergens op slaat (terwijl je nu suggereert dat application/download een zinnige betekenis heeft). Ook wel erg lomp dat je nu dubbele code moet gaan schrijven: eentje waarin je het goed doet en eentje waarin je het doet zoals het voor MSIE moet.
Wat doet MSIE5 eigenlijk fout bij application/octet-stream? Volgens mij moet dat ook gewoon werken. Waar baseer je je alternatief nu op? Ik mag toch hopen dat het niet gewoon giswerk/kopieerwerk is?

Ik heb deze code gewoon copy paste uit een ander code block gehaald. Het is niet mijn code. De precieze reden van het onderscheid weet ik niet precies maar neem van mij aan dat het onderscheid er niet voor niets is. IE gedroeg zich niet zoals het zich moest gedragen. Dat dat opgelost is met een niet bestaand content-type om IE voor de gek te houden is mijns inziens geen probleem. Als je wilt zal ik de CVS commits er bij halen om eens uit te zioeken waarom voor die (volgens jou niet zo nette) oplossing is gekomen.

offtopic:
Verder vind ik je PHP code erg lelijk; fout geindent, nutteloze initialisatie en nutteloze if-statements. Initialiseer je variabelen gewoon in één keer goed!

Het is gelukkig ook niet mijn code . Wat indentation betreft, de code was geindent en ik heb snel ff een paar leading spaces gedelete met als gevolg de wisselend indentatie. Lekker boeien voor een voorbeeld.
En wat var initialisatie betreft, Ik snap niet wat je bedoeld. Alle vars zijn netjes geinitialiseerd. Wanneer dat niet zo zal zijn dan zouden de downloads vernacheld worden aangezien ik default error reporting E_ALL heb en de errors naar screen redirect.
Ik ben ook niet van plan om elke lijn code netjes te maken want dan blijf ik aan de gang, Wat ik in dat project doe is dingen from scratch herschrijven en dan produceer ik alleen maar nette code. Dingen die op dit moment werken hebben geen prioriteit in het clean-up proces.

[stekkel]

En hier is de oorspronkelijke CVS commit (Mon Apr 23 21:47:53 2001 UTC) met het commentaar (had ik in het eerste blokje code weggehaald)

PHP:

          // Try to pop up the "save as" box
      // IE makes this hard.  It pops up 2 save boxes, or none.
      // http://support.microsoft.com/support/kb/articles/Q238/5/88.ASP
      // But, accordint to Microsoft, it is "RFC compliant but doesn't
      // take into account some deviations that allowed within the
      // specification."  Doesn't that mean RFC non-compliant?
      // http://support.microsoft.com/support/kb/articles/Q258/4/52.ASP
      //
      // The best thing you can do for IE is to upgrade to the latest
      // version
          if ($isIE) {
         // http://support.microsoft.com/support/kb/articles/Q182/3/15.asp
         // Do not have quotes around filename, but that applied to
         // "attachment"... does it apply to inline too?
         //
         // This combination seems to work mostly.  IE 5.5 SP 1 has
         // known issues (see the Microsoft Knowledge Base)
             header("Content-Disposition: inline; filename=$filename");
             
         // This works for most types, but doesn't work with Word files
             header("Content-Type: application/download; name=\"$filename\"");

             // These are spares, just in case.  :-)
             //header("Content-Type: $type0/$type1; name=\"$filename\"");
             //header("Content-Type: application/x-msdownload; name=\"$filename\"");
             //header("Content-Type: application/octet-stream; name=\"$filename\"");
      } else {
             header("Content-Disposition: attachment; filename=\"$filename\"");
         // application/octet-stream forces download for Netscape
             header("Content-Type: application/octet-stream; name=\"$filename\"");
      }

sorry voor de indentation, geen zin om dat te fixen.

[ Voor 15% gewijzigd door stekkel op 19-07-2003 13:08 ]

[alienfruit]

Waarom halen ze nou gewoon niet altijd zo'n CodeFormatter tooltje er over heen, scheelt al een stuk is natuurlijk niet perfect maar zulke if-block identie problemen voorkom je wel

Overigens een gezonde dosis commentaar

[ Voor 13% gewijzigd door alienfruit op 19-07-2003 12:54 ]

[Soultaker]

stekkel schreef op 19 juli 2003 @ 12:40:
En wat var initialisatie betreft, Ik snap niet wat je bedoeld. Alle vars zijn netjes geinitialiseerd.

Jawel, maar eerst worden $isIE en $isIE6 op 0 gezet en later ga je ze aan de hand van if-statements misschien weer op 1 zetten. Koppel dan direct de informele betekenis van de identifiers aan de initialisatie van de variabelen:

PHP:

$isIE  = strpos($HTTP_USER_AGENT, 'compatible; MSIE ')!==false &&
         strpos($HTTP_USER_AGENT, 'Opera')===false;
$isIE6 = $isIE && strpos($HTTP_USER_AGENT, 'compatible; MSIE 6')!==false;

Ik heb gelijk maar even die overbodige Opera-check verwijderd, want het is duidelijk dat $isIE6 onder $isIE valt ($isIE6 kan alleen 1 zijn als $isIE 1 is) en dat komt nu ook veel duidelijker naar voren. In ieder geval worden je variabelen nu maar op één plek ingesteld, zonder branching constructies, wat de code overzichtelijker maakt. (Overigens heb ik ook op nadrukkelijk advies van de PHP handleiding het gebruik van strstr vervangen door strpos).

Het zijn misschien kleine dingetjes, maar als ik zoveel kleine dingetjes bij elkaar zie in een klein stukje code, geeft me dat toch het gevoel van rommelige code. Zeker als de indentation dan ook nog niet klopt, want dat is wel het makkelijkste om goed te krijgen.

Ik ben ook niet van plan om elke lijn code netjes te maken want dan blijf ik aan de gang, Wat ik in dat project doe is dingen from scratch herschrijven en dan produceer ik alleen maar nette code. Dingen die op dit moment werken hebben geen prioriteit in het clean-up proces.

Accoord, maar kom dan niet met die huidige niet-nette code aanzetten met de opmerking "dit is de oplossing".

stekkel schreef op 19 July 2003 @ 12:50:
En hier is de oorspronkelijke CVS commit (Mon Apr 23 21:47:53 2001 UTC) met het commentaar (had ik in het eerste blokje code weggehaald)

Kijk, daar hebben we wat aan. Ik heb al zoveel varianten op zulke code gezien dat ik er niets van geloof dat iedereen goede redenen heeft om het anders te doen. Deze code is zo in ieder geval gebaseerd op daadwerkelijk gesignaleerde problemen. Dat is wel zo netjes. (Veel andere mensen hebben het argument: ik heb het wel eens ergens gezien en het werkt zo bij mij wel goed; dat het in een specificieke situatie lijkt te werken is namelijk geen garantie dat je het goed gedaan hebt!)

Een heel ander punt vind ik of je in je software rekening moet houden met bugs die bekend en gefixed zijn. In principe is de fout hier niet echt fataal (je krijgt een extra Save-as dialog te zien) en door de correcte code te genereren stimuleer je gebruikers ook om een correcte browser (upgrade) te installeren. Je kunt toch wel verwachten dat gebruikers zo af en toe een Windows Update (of iets anders, onder een ander besturingssysteem) draaien. Ik vind het wel gek dat je halverwege 2003 nog met een workaround uit 2001 te doen hebt. Ik zou dat soort code er nu zeker gewoon uit mikken, maar ik kan me voorstellen dat dat een persoonlijke (of beleidsmatige) afweging is.

[ Voor 8% gewijzigd door Soultaker op 19-07-2003 16:10 ]

[stekkel]

Soultaker schreef op 19 July 2003 @ 16:07:
[...]

Jawel, maar eerst worden $isIE en $isIE6 op 0 gezet en later ga je ze aan de hand van if-statements misschien weer op 1 zetten. Koppel dan direct de informele betekenis van de identifiers aan de initialisatie van de variabelen:

PHP:

$isIE  = strpos($HTTP_USER_AGENT, 'compatible; MSIE ')!==false &&
         strpos($HTTP_USER_AGENT, 'Opera')===false;
$isIE6 = $isIE && strpos($HTTP_USER_AGENT, 'compatible; MSIE 6')!==false;

Ik heb gelijk maar even die overbodige Opera-check verwijderd, want het is duidelijk dat $isIE6 onder $isIE valt ($isIE6 kan alleen 1 zijn als $isIE 1 is) en dat komt nu ook veel duidelijker naar voren. In ieder geval worden je variabelen nu maar op één plek ingesteld, zonder branching constructies, wat de code overzichtelijker maakt. (Overigens heb ik ook op nadrukkelijk advies van de PHP handleiding het gebruik van strstr vervangen door strpos).

Helemaal mee eens.
Het grappige is dat er nu precies een probleem wordt aangestipt waar ik al sinds ik programmeer voor SquirrelMail iedere keer weer tegen aanloop. Wanneer iets niet werkt dan wordt er een hack gedaan zodat het wel weer werkt. Na verloop van tijd is het een aan elkaar gehacked zootje (ik maak me daar zelf ook wel eens schuldig aan bij tijdgebrek, maar wie niet).
Op dat soort momenten zou je dus eigenlijk de code weer eens moeten reviewen en eens kijken wat het eigenlijk doet (thnx soultaker ).
Wat strstr betreft. Ik heb de functie zelf nog nooit gebruikt. Ik prevaleer ook strpos boven strstr.
Ik heb al veel overkill preg matches vervangen door strpos gebruik (waar mogelijk)

Begint nu overigens wel erg te kriebelen om toch maar een cleanup te doen voor de betreffende sectie, heb er nu al zoveel over geluld dat die update er ook nog wel bij kan

Accoord, maar kom dan niet met die huidige niet-nette code aanzetten met de opmerking "dit is de oplossing".

Ik bedoelde dit is zoals wij het doen. Ik heb nooit bedoeld dat het DE oplossing was

Een heel ander punt vind ik of je in je software rekening moet houden met bugs die bekend en gefixed zijn. In principe is de fout hier niet echt fataal (je krijgt een extra Save-as dialog te zien) en door de correcte code te genereren stimuleer je gebruikers ook om een correcte browser (upgrade) te installeren. Je kunt toch wel verwachten dat gebruikers zo af en toe een Windows Update (of iets anders, onder een ander besturingssysteem) draaien. Ik vind het wel gek dat je halverwege 2003 nog met een workaround uit 2001 te doen hebt. Ik zou dat soort code er nu zeker gewoon uit mikken, maar ik kan me voorstellen dat dat een persoonlijke (of beleidsmatige) afweging is.

Makkelijker gezegd dan gedaan. Binnen controleerbare groepen gebruikers is dat zeker te doen. Net zoals het veranderen van de minimale PHP versie vereisten.

Met webmail programma's die gerund woren door o.a. internetproviders met honderd duizenden gebruikers (heb zelfs aantallen van miljoenen gehoord) dan kan je gewoon niet verwachten dat elke gebruiker up2date is met de browser versie.

Je kan beter de workaround laten staan dan doodgegooid worden met klachten dat download niet meer werkt. Je moest eens weten hoeveel mensen er zijn die eenmaal w9x installeren met bijgeleverde IEx versie en nooit een upgrade doen.

[Soultaker]

stekkel schreef op 19 July 2003 @ 18:54:
Begint nu overigens wel erg te kriebelen om toch maar een cleanup te doen voor de betreffende sectie, heb er nu al zoveel over geluld dat die update er ook nog wel bij kan

Het mooiste zou zijn om dan gelijke de browserdetectie te verplaatsen naar een algemene module, want ik gok zo dat je op nog wel meer plaatsen in de code browser-afhankelijke code genereert (of is dit het enige)? Het vervelende van dit soort hacks is namelijk dat ze doorgaans slecht (elders) gedocumenteerd zijn en dat je na een jaar of 3 ontwikkelen onmogelijk kunt zeggen welke hacks voor welke issues waar geïmplementeerd zijn, zonder alle code af te lopen.

Met webmail programma's die gerund woren door o.a. internetproviders met honderd duizenden gebruikers (heb zelfs aantallen van miljoenen gehoord) dan kan je gewoon niet verwachten dat elke gebruiker up2date is met de browser versie.

Je kan beter de workaround laten staan dan doodgegooid worden met klachten dat download niet meer werkt. Je moest eens weten hoeveel mensen er zijn die eenmaal w9x installeren met bijgeleverde IEx versie en nooit een upgrade doen.

Dat klopt, maar de mensen die niet genoeg kennis of belanstelling hebben om de boel enigszins up to date te houden (we hebben het over drie jaar; dat is een compleet tijdperk in het worldwide web!), zijn ook de mensen die het geen reet kan schelen of 't systeem helemaal goed werkt. Die klikken gewoon maar wat in de rondte en als ze dan twee keer een Save-as dialog krijgen, dan klikken ze er wel eentje weg. Uiteraard gaat dit argument minder op als 't om een meer cruciale beperking gaat.

Ik ben het daarom met je eens dat de beslissing om dergelijke hacks er wel of niet in te houden nogal persoonlijk of tenminste beleidsmatig is en grootendeels afhankelijk van je doelgroep. Ik als ontwikkelaar vind zulke hacks lelijk en zou ze liever kwijt zijn, maar je gebruikers zijn waarschijnlijk voor het grootste deel geen ontwikkelaars en kan het allemaal niets schelen als het maar werkt. Een factor die je echter ook moet meenemen, is dat heldere code in betere (snellere en beter onhoudbare) applicaties resulteert, en daar is iedereen mee geholpen (ook de eindgebruiker).