mboost-dp1
Diskrimination af php scripts i IE 5?
Efter at min raid controller stod af her i weekenden var jeg nødt til at reinstallere Win2k pro.
Jeg besluttede mig ved samme lejlighed til lige at tjekke hvordan min nye lay out af en af mine sider tog sig ud i IE 5, ikke helt uventet var der en del galt - men det underligste var at php siderne og html siderne havde forskellige fejl...
Så jeg besluttede mig for at lave en test :
jeg fik IE til at vise et php script (t.php), valgte vis kode og gemte det som t.php.html, uploadede det til samme folder på serveren; de to sider t.php og t.php.html er nu identiske for browsere ( da det er samme html kode de får at gøre med ) - men alligevel var forskellen der : list images bliver flyttet 10px op og 10px til venstre hvis det er php siden der vises men html siden placerer dem hvor de skal.
Så medmindre MS har lavet to CSS / html parsere / viewers ( en til html og en til php ), så ligner det diskrimination mod php sider... ( og man skulle syntes at de er godt gammeldags molbo agtige hvis de HAR lavet 2 seperate parsere )
Det skal lige bemærkes at IE 6 viser begge sider ens.
ahh - det var rart lige at få lov til at brokke sig lidt ;)
Men er der nogen bud på hvorfor det er sådan? og hvordan man tvinger IE 5 til at vise dem ens?
Jeg besluttede mig ved samme lejlighed til lige at tjekke hvordan min nye lay out af en af mine sider tog sig ud i IE 5, ikke helt uventet var der en del galt - men det underligste var at php siderne og html siderne havde forskellige fejl...
Så jeg besluttede mig for at lave en test :
jeg fik IE til at vise et php script (t.php), valgte vis kode og gemte det som t.php.html, uploadede det til samme folder på serveren; de to sider t.php og t.php.html er nu identiske for browsere ( da det er samme html kode de får at gøre med ) - men alligevel var forskellen der : list images bliver flyttet 10px op og 10px til venstre hvis det er php siden der vises men html siden placerer dem hvor de skal.
Så medmindre MS har lavet to CSS / html parsere / viewers ( en til html og en til php ), så ligner det diskrimination mod php sider... ( og man skulle syntes at de er godt gammeldags molbo agtige hvis de HAR lavet 2 seperate parsere )
Det skal lige bemærkes at IE 6 viser begge sider ens.
ahh - det var rart lige at få lov til at brokke sig lidt ;)
Men er der nogen bud på hvorfor det er sådan? og hvordan man tvinger IE 5 til at vise dem ens?
Virker yderst underligt da det jo er serveren der konverterer PHP scriptet til html.
Kan det ikke være at du har lavet en fejl i din PHP-kode som resultere i en fejl i HTML-koden. Man kunne så forestille sig at de to browsere vælger at rette fejlen på forskellig vis, inden de viser siden. Det er kun et forslag, men synes at det lyder mest sandsynligt!
Kan det ikke være at du har lavet en fejl i din PHP-kode som resultere i en fejl i HTML-koden. Man kunne så forestille sig at de to browsere vælger at rette fejlen på forskellig vis, inden de viser siden. Det er kun et forslag, men synes at det lyder mest sandsynligt!
Det lyder meget mærkeligt. Browseren kan jo ikke vide noget om, at der er tale om et php-script. Det behandles jo udelukkende af serveren.
#4 IE kan faktisk godt finde på at reagere alt efter extension....
fx. kan du på din webserver sig at .log filer skal fortolkes som text/plain, men IE behandler dem stadig som om de skal downloades og gemmes eller åbnes
tror nu ikke lige det er tilfældet her... i øvrigt er der snart gået et år, mon ikke han har fået lortet til at virke?
fx. kan du på din webserver sig at .log filer skal fortolkes som text/plain, men IE behandler dem stadig som om de skal downloades og gemmes eller åbnes
tror nu ikke lige det er tilfældet her... i øvrigt er der snart gået et år, mon ikke han har fået lortet til at virke?
det er jo ligesom den bug der gør at du kan indlæse en .png / .gif med rigtig content type som et html document.
En bug der er kendt og elsket af mirc brugere.
Anyway: tjek at din server er sat op til at servere siderne med korrekt content-type, og at du har den korekte content-type både i header og meta tagget i toppen af siden.
Hvis serveren er sat rigtigt op, kan du evt. søge efter en header() kommando, der kan override serverens content-type.
edit: hov ja, så ikke lige på dato, lad os da håbe hans sider kører nu :(
En bug der er kendt og elsket af mirc brugere.
Anyway: tjek at din server er sat op til at servere siderne med korrekt content-type, og at du har den korekte content-type både i header og meta tagget i toppen af siden.
Hvis serveren er sat rigtigt op, kan du evt. søge efter en header() kommando, der kan override serverens content-type.
edit: hov ja, så ikke lige på dato, lad os da håbe hans sider kører nu :(
#6 du har vist misforstået mig...
DET ER IKKE EN BUG at man kan loade en fil der ender på JPG som html kode... det er fordi at HTTP i følge standarden slet ikke kigger på filnavnet, men udelukkende på content type
det som jeg prøver at sige, er at IE har en tendens til at kigge på filnavnet, selv om man bruger en anden content type... ergo behandler den ikke to filer med indholdet text/plain på samme måde, hvis den ene hedder .txt og den anden hedder .log
DET ER IKKE EN BUG at man kan loade en fil der ender på JPG som html kode... det er fordi at HTTP i følge standarden slet ikke kigger på filnavnet, men udelukkende på content type
det som jeg prøver at sige, er at IE har en tendens til at kigge på filnavnet, selv om man bruger en anden content type... ergo behandler den ikke to filer med indholdet text/plain på samme måde, hvis den ene hedder .txt og den anden hedder .log
Uhm. jeg misforstod vidst mere mig selv :)
Jeg mener netop den bug i IE bestod i at den ikke fulgte content-type, men filtypen. Loadede du et af de billeder der blev spammet på irc, i mozilla fik du en fejl om at billedet var corrupt.
Dvs der er den rigtige filtype og content-type image/png, men det er en html fil den loader.
Jeg mener netop den bug i IE bestod i at den ikke fulgte content-type, men filtypen. Loadede du et af de billeder der blev spammet på irc, i mozilla fik du en fejl om at billedet var corrupt.
Dvs der er den rigtige filtype og content-type image/png, men det er en html fil den loader.
nu tror jeg du blander en 3. ting ind her: indholdet...
det du snakker om nu, er at hvis filnavnet hedder noget med .png, og typen er image/png, bliver dette udført som HTML hvis det indeholder et tag?
men jeg ved ik helt når du siger filtype, er det så på baggrund af filnavnet i URLen eller indholdet?
det du snakker om nu, er at hvis filnavnet hedder noget med .png, og typen er image/png, bliver dette udført som HTML hvis det indeholder et tag?
men jeg ved ik helt når du siger filtype, er det så på baggrund af filnavnet i URLen eller indholdet?
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund