email adres plaatje in profile werkt niet in Konqueror - Stoute bugs

dinsdag 4 maart 2003 23:51

Acties:

0 Henk 'm!

Topicstarter

Heel duister dacht ik zo. Maar, na enig staren naar een Ethereal snif denk ik waarom ik geen email/msn/whatever plaatje zie die dynamisch gegenereerd word.

Als je een profile pagina opvraagt dan stuurt konqueror onderandere deze http header: "Accept: image/x-krl, image/x-portable-bitmap, image/x-xbm, image/x-ico, image/png, image/x-portable-pixmap, image/jpeg, image/x-xpm, image/x-eps, image/tiff, image/x-bmp, image/gif"

Leuk en aardig maar daar krijg je een 406 van apache terug met als enige content alternatief een "application/x-httpd-php", en dat voldoet weer niet aan de vraag van konqueror dus einde verhaal -> geen plaatje.

MAAR, hier komt het, als je de locatie van het plaatje in je adresbalk zet, dan doet konqueror plotseling een andere Accept header sturen, nl: "Accept: text/*, image/jpeg, image/png, image/*, */*"

Heel erg mooi natuurlijk. Hieruit komt een plaatje rollen met "Content-Type: image/jpeg" en voila een plaatje.

Het grootste verschil is denk ik de "*/*" die apache (julie webserver) accepteerd als "acceptable" en dan dat de php-code er uiteindelijk toch weer een "image/jpeg" van maakt, allemaal prima. Maaaar als apache dus een php-tje wilt uitvoeren die "application/x-httpd-php" is en de browser accepteerd dus alleen plaatjes-mime-typen, ja dan gaat het fout. Dus, de oplossing is simpel, verander het mechanisme zo dat apache denkt dat een php'tje ook een plaatje kan uitpoepen.

Oja, een zelfde trend is ook op tweakers.net zichtbaar (geen plaatjes te zien in konqueror), maar daar heb ik niet onderzocht of dat hetzelfde probleem is.

Dus... leuk om eens uit te zoeken

, nu ga ik slapen, het is al eigenlijk sinds een uur dino7 bedtijd

https://github.com/atoomnetmarc/

woensdag 5 maart 2003 00:02

Acties:

0 Henk 'm!

DiNo!

Topicstarter

DiNo7 schreef op 04 March 2003 @ 23:51:

Oja, een zelfde trend is ook op tweakers.net zichtbaar (geen plaatjes te zien in konqueror), maar daar heb ik niet onderzocht of dat hetzelfde probleem is.

Probleem is het zelfde op de FP icm Konqueror.
Hier een snappie:

code:

GET http://www.tweakers.net/ext/i/1043541819.gif HTTP/1.1
Connection: close
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; X11; i686; nl)
Referer: http://www.tweakers.net/
Accept: image/x-krl, image/x-portable-bitmap, image/x-xbm, image/x-ico, image/png, image/x-portable-pixmap, image/jpeg, image/x-xpm, image/x-eps, image/tiff, image/x-bmp, image/gif
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: nl, en
Host: www.tweakers.net
Cookie: tc=allemaalleukelettertjescijfertjes; phpAds_blockAd[96]=allemaalleukelettertjescijfertjes; unq=y

HTTP/1.0 406 Not Acceptable
Date: Tue, 04 Mar 2003 22:57:43 GMT
Server: Apache/1.3.27 (Unix) PHP/4.2.2 mod_gzip/1.3.19.1a
Alternates: {"i.dsp" 1 {type application/x-httpd-php} {length 4263}}
Content-Type: text/html; charset=iso-8859-1


<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>406 Not Acceptable</TITLE>
</HEAD><BODY>
<H1>Not Acceptable</H1>
An appropriate representation of the requested resource /ext/i/1043541819.gif could not be found on this server.<P>
Available variants:
<ul>
<li><a href="i.dsp">i.dsp</a> , type application/x-httpd-php
</ul>
<HR>
<ADDRESS>Apache/1.3.27 Server at www.tweakers.net Port 80</ADDRESS>
</BODY></HTML>

https://github.com/atoomnetmarc/

woensdag 5 maart 2003 00:57

Acties:

0 Henk 'm!

Kees

Serveradmin / BOFH / DoC

Het probleem is dat Konqueror geen Accept: */* meestuurt, waardoor apache denkt dat Konqueror de request niet aankan, want die ziet apache als application/php. Ik weet niet bij wie de fout ligt, wat ik wel weet is dat de meeste webbrowsers het wel goed doen

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan

woensdag 5 maart 2003 10:00

Acties:

0 Henk 'm!

chem

Reist de wereld rond

probleem is bekend, ligt echt aan konq's afhandeling van de afbeelding.

Klaar voor een nieuwe uitdaging.

zondag 9 maart 2003 13:12

Acties:

0 Henk 'm!

Raymond

Dino heeft wat extra info en wil dit graag delen:
BUG melding topic weer openen voor meer info
Aangezien hij een mooi verhaaltje heeft geschreven doe ik deze weer even open, dan kan namelijk de SeM dicht

zondag 9 maart 2003 17:44

Acties:

0 Henk 'm!

DiNo!

Topicstarter

Ik zal mijn reactie uit het SM topic wel hier even dupliceren:

Door DiNo7 - Wednesday 05 March 2003 12:03

Reactie die ik had gepland voor in de bugmelding:

Kees/Chem, als Konqueror een */* moet sturen zoals alle andere browsers ter wereld(?), dan is toch heel het HTTP content negotiation overbodig geworden?. Ik ben het met je eens dat dit een bijzonder geval is wat betreft wat nu fout is, maar ik heb zo het idee dat Konqueror het goed doet volgens de http specificatie.
Wat ik dus zie wat er verbeterd kan worden is dat apache en het php script alletwee van op de hoogte zijn wat ze kunnen, immers als je */* stuurt krijg je van het script een "image/jpeg" terug, dus je zou verwachten dat als je alleen een "Accept: image/jpeg" stuurt naar de webserver dat je dan een plaatje terug krijgt van het script.

Kijk eens aan (met RFC verwijzingen) -> http://httpd.apache.org/docs/content-negotiation.html. In dit document wordt beschreven hoe je een type map kan aanmaken voor de juiste content negotiation. Dus ik heb zo het idee als je dit in een type.map zet dat het spontaan begint te werken:
code:
code:
1
2
URI: i.dsp
  Content-type: image/jpeg
Door DiNo7 - Wednesday 05 March 2003 14:52

quote:
vrotogel schreef op 05 maart 2003 @ 14:19:
Lees anders odysseus in "KDE 3.1 uit - post hier ervaringen en pr" eens door

Dit is niet de oplossing voor het probleem, maar een verbandje op een probleem die niet eens in Konqueror zit, lees de RFCs maar door, of in ieder geval het document van de apache website. Ik blijf erbij dat de apache webserver anders ingesteld moet worden door middel van een type.map die de juiste mime-typen insteld voor het php bestand wat de plaatjes maakt.
Als ik in de source van konqueror een fix moet schrijven dat in feite heel content-negotiation uitzet dan kan je net zogoed heel deze (mooie!) techniek afschaffen.

Nee, sorry ik kan hier niet inkomen, en het is zo makkelijk te fixen. Ik hoop dan ook dat de diverse developers er nog eens een nachtje over slapen en het rustig te laten bezinken

wat mij betreft mag het SM-topic weg.

Zijn er al intressante ontwikkelingen?

https://github.com/atoomnetmarc/

maandag 10 maart 2003 14:23

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Volgens mij bepaalt apache op basis van de extentie welke content-type ie intern moet gebruiken. Op basis van die content-type wordt van vervolgens bepaald welke actie er uitgevoerd moet worden...
Als er dan voor i.dsp staat 'dit is een plaatje', dan zal die niet meer door de php-module gehaald worden lijkt me.
[/speculatie]

Anyway, ik heb het thuis geprobeerd te testen a.d.h.v. die url van je, maar ik kreeg het niet voor elkaar uberhaupt een werkende type-map te regelen...

code:

root@server type # more *
::::::::::::::
bla.bla
::::::::::::::
<b>Bla</b>
::::::::::::::
test.php
::::::::::::::
<?
        echo '<b>bla</b>';
?>
::::::::::::::
type.var
::::::::::::::
URI: test.php
Content-type: text/plain

URI: bla.bla
Content-type: text/html

Bij de bla.bla kreeg ik netjes plain-text en bij de test.php netjes dik gedrukt de bla.

Btw, content-negotiation wordt ook nog voor iets anders gebruikt... Namelijk de /-url's hier voor vrijwel elke pagina...

maandag 10 maart 2003 16:52

Acties:

0 Henk 'm!

DiNo!

Topicstarter

Als je dat wil dan kan ik eens deze hele theorie op mijn servertje uittesten en het je laten weten of het werkt.
Ik heb een vraag voor je: kan je een test-php bestand posten die hetzelfde gedrag heeft als de i.dsp, dan kan ik het zo bij mij uitzoeken dat het misschien wel gaat werken. Dan ga ik het hele zaakje eens testen met KDE's Konqueror en mijn apache server.

https://github.com/atoomnetmarc/

maandag 10 maart 2003 17:46

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

PHP:

<?
header('Content-Type: image/jpeg');
readfile('test.jpg');
?>

Zou al moeten werken, tenminste als je een test.jpg in dezelfde dir plakt

maandag 10 maart 2003 19:39

Acties:

0 Henk 'm!

DiNo!

Topicstarter

IK HEB HET! (o sorry, niet schreeuwen

).

http://dino.dyndns.org/phpplaatje/ is mijn testje.

ik heb de type-map handler aangezet (stond uit in httpd.conf) en ik heb op mijn server multiviews aan moeten zetten.

website.html: hier staan 2 <img> tags met 1 werkend plaatje volgens het *.var principe (plaatje) en een niet werkend plaatje (plaatjewerktnietinkde) onder kde.
Door de multiviews gaat apache automatisch alle plaatje.* bestanden af, hierbij is het php bestand (application/x-httpd-php) niet goed voor Konqueror (406, not acceptable, want image/* != application/x-httpd-php)

Maar ok, hier de clou, maak een .var bestand aan met dezelfde naam als het multiview-bestandsnaam+.var dus-> plaatje.var, want mijn multiview url is './plaatje'.

Stop dit erin:

code:

1 2	URI: plaatje.php Content-type: image/jpeg

en voila probleem opgelost (bij mij)

oja, niet vergeten de type-map handler aan te zetten: httpd.conf

code:

    #
    # To enable type maps, you might want to use
    #
    AddHandler type-map var

Dus, hebben die kip!

https://github.com/atoomnetmarc/

maandag 10 maart 2003 19:40

Acties:

0 Henk 'm!

DiNo!

Topicstarter

oja, volgende keer niet meer blind Konqueror de schuld geven he?

https://github.com/atoomnetmarc/

maandag 10 maart 2003 19:51

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

DiNo7 schreef op 10 maart 2003 @ 19:40:
oja, volgende keer niet meer blind Konqueror de schuld geven he?

Wel hoor, want Konqueror is de enige die het anders doet

En je kan wel dit soort dingen blijven doen voor de verschillende files/situaties, maar het is wel een soort workaround imho. Hopelijk is het voorn met plaatjes lastig, magoed.

dinsdag 11 maart 2003 14:55

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Een klein nadeel is trouwens dat de url voor de email-plaatjes dezelfde is als voor de rest van het forum, daardoor kan je niet domweg de content-type ervan zetten...
Want zodra een browser Accept: text/* doet zit je met hetzelfde probleem.

dinsdag 11 maart 2003 17:36

Acties:

0 Henk 'm!

DiNo!

Topicstarter

http://gathering.tweakers...gfx/49016/AAAAE6/000000/1

Als user_email_gfx de multiview naam is, en user_email_gfx.php de scriptnaam, dan ben je toch klaar als je een user_email_gfx.var type-map aanmaakt, of zie ik het nu verkeerd?

https://github.com/atoomnetmarc/

dinsdag 11 maart 2003 17:55

Acties:

0 Henk 'm!

Kees

Serveradmin / BOFH / DoC

ja, want de multiviewnaam is forum, en niet user_email_gfx.

Het is op deze manier dus niet mogelijk. Wat ik wel jammer vind is dat apache niet gewoon de php parsed en dan aan de hand van de headers bepaalt of het al dan niet goed is.

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan

dinsdag 11 maart 2003 20:32

Acties:

0 Henk 'm!

DiNo!

Topicstarter

mmm, balen. Dan zou de enige oplossing zijn om een forum.var te maken met de inhoud:

code:

1 2	URI: forum.php Content-type: /

Als dit legaal zou zijn, dan laat je inweze het content-negatiation puur aan forum.php over (wat het eigenlijk al deed, maar dan stuurden de browsers een */* mee wat eigenlijk apache's logica omzeilde).

https://github.com/atoomnetmarc/

dinsdag 11 maart 2003 22:49

Acties:

0 Henk 'm!

DiNo!

Topicstarter

YEAH baby!
probeer dit eens voor je forum.var type map:

code:

1 2	URI: forum.php Content-type: application/x-httpd-cgi

Deze type map heb ik nu op mijn server draaien en het werkt, het is een magic mime type, deze kwam ik tegen toen ik maar de source van mod_negotiation ging doorlezen (wat iemand uit wanhoop doet he?

).
Wat ik ervan begrijp is dat het hele TCN door het script gedaan wordt.

https://github.com/atoomnetmarc/

woensdag 12 maart 2003 10:45

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Toevallig ook gezien of application/x-httpd-php dan niet gewoon als magic mime type toegevoegd kan worden?

Ow en wat is een TCN?

woensdag 12 maart 2003 11:27

Acties:

0 Henk 'm!

DiNo!

Topicstarter

Volgens de handleiding zijn alle mime types die aan de handler cgi-script zijn verbonden door addhandler automatisch een magic mime type, alleen heb ik geen idee wat daar de uitwerking van zou zijn. Ik bedoel, misschien gaat dan het php script niet meer door php uitgevoerd worden, ik denk dat we dat zouden moeten testen. Vanavond zit ik weer bij mijn testserver om het te testen als jij het niet al gedaan hebt.
TCN: Transparent Content Negotiation. Dat doet apache voor je als je een multiview file aanroept, apache maakt dan automatisch de type-map aan met de mime-types die bij alle matchende files horen (in ons geval op een verkeerde mannier dus).

https://github.com/atoomnetmarc/

donderdag 13 maart 2003 20:40

Acties:

0 Henk 'm!

DiNo!

Topicstarter

ACM schreef op 12 March 2003 @ 10:45:
Toevallig ook gezien of application/x-httpd-php dan niet gewoon als magic mime type toegevoegd kan worden?
....

Nee, dat kan niet volgens mij, wat ik hierboven heb beschreven werkt ook niet. Dus de enige (en goede) oplossing is door een type-map aan te maken met application/x-httpd-php als mime type voor het php script.

https://github.com/atoomnetmarc/

donderdag 13 maart 2003 20:42

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Die mime-type hebben ze default via de httpd.conf al, anders worden ze niet eens door de php-engine opgepakt

Of maak je nu een tikfoutje?

donderdag 13 maart 2003 22:05

Acties:

0 Henk 'm!

DiNo!

Topicstarter

ACM schreef op 13 March 2003 @ 20:42:
Die mime-type hebben ze default via de httpd.conf al, anders worden ze niet eens door de php-engine opgepakt

Of maak je nu een tikfoutje?

Nee, wat ik bedoelde is dat als je .php aan de cgi-script handler hangt (om het als magic-mime te laten herkennen) dan was het plan dat je niet die type-map hoeft aan te maken, maar zoals ik al vermoedde gaat apache alle .php scripts uitvoeren als een .cgi.

https://github.com/atoomnetmarc/

maandag 17 maart 2003 23:25

Acties:

0 Henk 'm!

DiNo!

Topicstarter

maar, en, dus? Nog hulp nodig?

https://github.com/atoomnetmarc/

dinsdag 18 maart 2003 00:34

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Humm, je hoeft niet perse te schoppen hoor

Maar net even getest/aan de praat gekregen.

Het werkt wel, hoewel ik het eigenlijk stiekem een vieze oplossing vindt... Simpelweg omdat je nu het Accept: */* principe gewoon bij de server legt, ipv dat je dit door de browser laat doen...
Maar goed, ik zal Kees es aan het werk zetten om het te regelen

dinsdag 18 maart 2003 10:50

Acties:

0 Henk 'm!

DiNo!

Topicstarter

ACM schreef op 18 March 2003 @ 00:34:
Humm, je hoeft niet perse te schoppen hoor
....

Sorry

, ik was een beetje ongeduldig aan het worden.
Ik zal vanavond eens kijken of de hele truuk ook heeft gewerkt, teminste ik neem aan dat het in de loop van vandaag ingesteld gaat worden.

https://github.com/atoomnetmarc/

dinsdag 18 maart 2003 11:21

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Nou... ik weet nog niet of het uberhaupt al ingesteld is.
En zou ook niet weten wanneer wel, 't is niet dat het topprioriteit heeft en Kees heeft het al vrij druk met andere zaken

zaterdag 7 februari 2004 17:38

Acties: