[PHP/Tomcat] GD werkt niet zoals het hoort

[T i M]

Ik heb momenteel een testmachine draaien met Tomcat 5.0.28 en PHP 5.2.5 op een Windows omgeving (XP). PHP werkt, dat was geen enkel probleem. Voor een project heb ik ook de GD Library nodig, die heb ik geenabled in de php.ini en wordt netjes geladen.

Het probleem is dat ik geen plaatje kan genereren. In IE krijg ik een kruisje te zien en FF geeft de volgende melding: The image “http://url/file.php” cannot be displayed, because it contains errors.

De code die ik gebruikt heb komt rechtstreeks van PHP.net af en werkt op een Apache 2/PHP omgeving.

PHP:

<?php

// create a blank image
$image = imagecreatetruecolor(400, 300);

// fill the background color
$bg = imagecolorallocate($image, 0, 0, 0);

// choose a color for the ellipse
$col_ellipse = imagecolorallocate($image, 255, 255, 255);

// draw the white ellipse
imagefilledellipse($image, 200, 150, 300, 200, $col_ellipse);

// output the picture
header("Content-type: image/png");
imagepng($image);

?> 

Niks geks dus.

Ik heb gegoogled en kom genoeg onderwerpen tegen, maar helaas staan er geen oplossingen tussen. Ik heb al een andere versie van PHP en GD geprobeerd, maar dat is de oplossing niet. Een andere versie van Tomcat is geen optie.

[hostname]

Kijk eens naar welke output je nu werkelijk krijgt. In firefox kan dat geloof ik door View Source te doen, maar je kan ook even tijdelijk de header() regel uit-commenten.

(op mijn LAMP met 5.3 draait je script trouwens wel gewoon goed, dus het lijkt me niet echt een programmeerprobleem maar eerder een installatie probleem, die volgens mij in WSS horen).

[Creepy]

Gewoon even debuggen lijkt me? Zeer waarschijnlijk krijg je iets van een foutmelding. Die kan je zien als je de header() even weghaalt. Debuggen is wat anders dan googlen als er iets mis gaat

[NMe]

Of anders kijk je eens gewoon in de FAQ... Programming FAQ - Image manipulation in PHP

[T i M]

Mijn post was blijkbaar niet helemaal volledig.

Ik ben mijn script gaan debuggen, maar het vreemde is dat ik geen errors of warnings krijg. Als ik het header() gedeelte afster krijg ik de volgende uitvoer:

code:

‰PNG IHDRbÕrIDATxœíÜkN#I…ÑèÙÿž{~0*z€6IŸIEND®B

Lijkt op een correcte uitvoer. En zoals ik al zei, op een Apache/PHP omgeving werkt het stukje PHP script wél.

Daarbij heb ik het scriptje gecontroleerd op enters en whitespaces, die heb ik weggehaald en het header() gedeelte op de 1e regel gezet. Het probleem lijkt dieper te zitten, vandaar dat ik dit topic heb geopend.

[Creepy]

Is dat letterlijk je output? Want die &#8240 hoort daar echt niet. Voor de letters PNG hoort maar 1 byte te komen (137 decimaal). Het lijkt erop alsof de data nu wordt aangepast/omgezet naar iets anders

[NMe]

Doe eens alt+0137 en doe daarna eens ‰ intikken op dit forum, Creepy.

Staan die HTML entities ook in je code of doet onze forumsoftware dat, T i M?

[Cartman!]

‰ ‰

code:

‰ ‰

edit: forum zet t om naar entities, t zou dus ook daadwerkelijk die pro-mile kunnen zijn. Nog vaag dan

[ Voor 100% gewijzigd door Cartman! op 27-10-2009 23:13 ]

[NMe]

Overigens verdenk ik nog steeds whitespace. Ben je er écht zeker van dat er geen witruimte voor of achter de image data staat?

[dragontje124]

was er niet iets met het opslaan als UTF-8 waardoor er een teken aan het begin van de php file geplaatst wordt?

[NMe]

Ja, maar hier wordt niks opgeslagen en tenzij je het expliciet aangeeft (wat de topicstarter niet doet aan zijn code te zien) wordt er geen UTF-8 encoding gebruikt.

[Cartman!]

Eerder een BOM (Byte Order Mark) in de php file zelf NMe, niet in de image. Dat teken komt niet overeen met ‰ overigens dus dat lijkt me overigens sterk.

[dragontje124]

Cartman! schreef op dinsdag 27 oktober 2009 @ 23:40:
Eerder een BOM (Byte Order Mark) in de php file zelf NMe, niet in de image. Dat teken komt niet overeen met ‰ overigens dus dat lijkt me overigens sterk.

dat bedoelde ik!
njah als het niet overeenkomt met ‰ zal het wel niet zo zijn

[B-Man]

Dit lijkt me eerder aan de combinatie tomcat+php te liggen dan aan je script. Kun je wat meer informatie geven over je config, zoals: hoe je php binnen tomcat hebt draaien? (Middels Quercus?).

[NMe]

B-Man schreef op woensdag 28 oktober 2009 @ 00:31:
Dit lijkt me eerder aan de combinatie tomcat+php te liggen dan aan je script. Kun je wat meer informatie geven over je config, zoals: hoe je php binnen tomcat hebt draaien? (Middels Quercus?).

Ik weet bijna zeker dat die HTML-entities door ons forum zo zijn weergegeven. Waarop baseer je dat het überhaupt aan Tomcat zou kunnen liggen?

[B-Man]

NMe schreef op woensdag 28 oktober 2009 @ 00:41:
[...]
Ik weet bijna zeker dat die HTML-entities door ons forum zo zijn weergegeven. Waarop baseer je dat het überhaupt aan Tomcat zou kunnen liggen?

De TS geeft aan dat het script prima werkt onder php/apache, maar niet werkt onder php/tomcat. Als die extra byte die de TS aan het begin van zijn output heeft staan niet door het script gegenereerd wordt, kan het zomaar zo zijn dat tomcat die invoegt (alle output een BOM meegeven voor utf-8 omdat hij text/html verwacht door te geven?). Zo heeft apache de bekende AddDefaultCharset directive, waarbij een centrale instelling ook de invloed heeft (maar weliswaar de output niet aanpast, enkel de headers).
Daarom vraag ik de TS om toe te lichten welke configuratie hij precies draait, zodat ik kan achterhalen hoe e.e.a. ingesteld is.

[HuHu]

Je kunt sowieso de laatste ?> uit je bestand weghalen. Dat voorkomt problemen met eventuele white space aan het einde van je bestand.

For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response.

Bron: http://framework.zend.com...p-file-formatting.general

[Matis]

Ik heb net even jouw scripje 1:1 gekopieerd naar mijn pc en gedraaid op Win 7 + Wamp 2.0i (Apache 2.2.11
+ PHP 5.3.0).

Het werkt prima, de eerste bytes van het bestand zijn dan ook

code:

89 50 4E 47

Het promille-teken, P, N, G.

Welke GD-versie heb jij volgens php-info? En libPNG?

Wat gebeurt er overigens als je geen png, maar bijvoorbeeld jpg gebruikt als bestand?

[ Voor 14% gewijzigd door Matis op 28-10-2009 09:05 ]

[T i M]

Ik heb deze tutorial gevolgd om PHP aan de praat te krijgen onder Tomcat. http://nexus.zteo.com/200...setup-php5-with-tomcat-5/

De uitvoer van het plaatje onder Apache is totaal anders:


De GD info:

code:

GD Support  enabled
GD Version  2.0.35
FreeType Support    enabled
FreeType Linkage    with freetype
FreeType Version    2.3.9
T1Lib Support   enabled
GIF Read Support    enabled
GIF Create Support  enabled
JPEG Support    enabled
libJPEG Version     7.0
PNG Support     enabled
libPNG Version  1.2.35
WBMP Support    enabled
XBM Support     enabled

Whitespaces staan er niet meer in:

PHP:

<?php
header("Content-type: image/png");
$image = imagecreatetruecolor(400, 300);
$bg = imagecolorallocate($image, 0, 0, 0);
$col_ellipse = imagecolorallocate($image, 255, 255, 255);
imagefilledellipse($image, 200, 150, 300, 200, $col_ellipse);
imagepng($image);

JPG gebruiken ipv PNG maakt niet uit, resultaat is hetzelfde, geen plaatje.

[ Voor 97% gewijzigd door T i M op 28-10-2009 11:45 ]

[T i M]

NMe schreef op woensdag 28 oktober 2009 @ 00:41:
[...]

Ik weet bijna zeker dat die HTML-entities door ons forum zo zijn weergegeven. Waarop baseer je dat het überhaupt aan Tomcat zou kunnen liggen?

Omdat de fout niet in het script zit en de configuratie van PHP is hetzelfde als op Apache. Daarbij zijn er meerdere mensen die hetzelfde probleem hebben.

Dus ja, het kan zeker wel in de configuratie van Tomcat zitten of op de manier waarop PHP geladen wordt. Je hebt wel gelijk dat de HTML-entities door het forum zijn gegenereerd, dat heb ik zojuist gecontroleerd.

[ Voor 9% gewijzigd door T i M op 28-10-2009 11:51 ]

[Creepy]

De uitvoer van php via tomcat is een stuk korter. Kan het niet iets zijn dat er in de binaire data een EOF teken of een 0 (als in: ascii code 0) voorkomt en dat tomcat daardoor er vanuit gaat dat het einde van de output is bereikt en gewoon de boel afkapt?

http://forums.devnetwork.net/viewtopic.php?f=40&t=85204 lijkt hetzelfde probleem te zijn en daar geven ze als tip om te controleren of outputbuffering uit staat en als dat niet het geval is die uit te zetten.

[ Voor 29% gewijzigd door Creepy op 28-10-2009 12:43 ]

[T i M]

Die webpagina ben ik ook tegengekomen en output buffering staat default op Off heb ook 0 als waarde geprobeerd, maar dat maakt geen verschil.

[HuHu]

De headers die bij je browser binnen komen kloppen ook? Want je doet in PHP een Content-type: image/png, maar krijgt je browser dat ook zo binnen? Of vervangt Tomcat het stiekem voor een andere content-type header?

[T i M]

HuHu schreef op woensdag 28 oktober 2009 @ 13:15:
De headers die bij je browser binnen komen kloppen ook? Want je doet in PHP een Content-type: image/png, maar krijgt je browser dat ook zo binnen? Of vervangt Tomcat het stiekem voor een andere content-type header?

Ja, die kloppen.

[NMe]

T i M schreef op woensdag 28 oktober 2009 @ 11:40:
Whitespaces staan er niet meer in:

PHP:

<?php
header("Content-type: image/png");
$image = imagecreatetruecolor(400, 300);
$bg = imagecolorallocate($image, 0, 0, 0);
$col_ellipse = imagecolorallocate($image, 255, 255, 255);
imagefilledellipse($image, 200, 150, 300, 200, $col_ellipse);
imagepng($image);

JPG gebruiken ipv PNG maakt niet uit, resultaat is hetzelfde, geen plaatje.

Laten we dat misverstand even uit de wereld helpen. Met overbodige whitespace doelden we op whitespace vóór de <?php en/of na de ?>. Wat je binnen PHP tags aan whitespace opneemt mag je helemaal zelf weten, zelfs al zet je het helemaal vol met witruimte.

[dragontje124]

wat je ook kan doen is voordat je je je image door php laat printen even de output buffer te legen dmv:

code:

ob_clean()

[NMe]

Als je nergens een output buffer hebt gestart doet ob_clean helemaal niks.

[T i M]

Ik heb nog eens het internet afgezocht, maar kan geen oplossing vinden. Wat ik wel het gevonden is een tutorial om PHP op een andere manier te installeren op de Tomcat server. Via de CGI module? Daar kan het probleem ook niet liggen, maar ik ga het toch proberen.

[Cartman!]

En gewoon, puur als test, er apache naast draaien op een andere poort? Als het dan ook faalt hoef je t iig. niet meer bij Tomcat te zoeken, anders wel.

[T i M]

Als je het hele topic had doorgelezen dan wist je dat dat het eerste is wat ik heb geprobeerd . Ik heb het inmiddels opgegeven, maar als iemand nog goede ideeen heeft zijn die altijd welkom.

Ik draai nu 2 webservers naast elkaar. Verspilling van resources maar het is even niet anders.

[Salandur]

heb je al gekeken of je phpservlet goed is geconfigureerd? Misschien gaat het daar fout. Werkt een bestandje met daarin alleen

PHP:

<?php
phpinfo();

wel goed?

Daarnaast, heb je jouw systeem goed ingericht en de PHP_HOME environment variable goed gezet?

[ Voor 21% gewijzigd door Salandur op 03-11-2009 11:40 ]

[Cartman!]

T i M schreef op dinsdag 03 november 2009 @ 11:26:
Als je het hele topic had doorgelezen dan wist je dat dat het eerste is wat ik heb geprobeerd . Ik heb het inmiddels opgegeven, maar als iemand nog goede ideeen heeft zijn die altijd welkom.

Ik draai nu 2 webservers naast elkaar. Verspilling van resources maar het is even niet anders.

Ik had enkel gelezen dat je 'ergens' ook een apache/php install had, maar er stond zover ik lees niet bij of dit op dezelfde machine is, dat kan natuurlijk een wereld van verschil betekenen.

[jelmervos]

Al es een diff gedaan tussen de uitvoer van Apache en Tomcat van dezelfde PHP code?