Saját web browser PHP oldalak megjelenítése

Java

Sziasztok!

Az alábbi linken található egy kis web browser program (MiniBrowser néven):

http://forums.devx.com/showthread.php?threadid=149187

Ez viszonylag jól megjeleníti a HTML fájlokat, viszont olyan esetekben, amikor PHP által generált oldalakat kellene megjeleníteni, csődöt mond.

Hogyan kell tovább építenem a programot, hogy a PHP oldalak is helyesen jelenjenek meg?

  • 3689 megtekintés

( asch v | 2010. 02. 20., szo – 00:37 )

Szia!

Ha valóban választ vársz, akkor ne bízd a válaszadóra, hogy végigolvassa a fórumot, hanem írd le minél rövidebben, hogy mi a megoldásod ami nem működik.

Egyébként elvileg teljsen mindegy, hogy egy HTML-t milyen nyelven írt program generál, tehát nem a PHP lesz a gond.

Lehet, hogy nekem is az apache irányában kell keresgetnem a megoldást?

Ugyanazt a PHP oldalt, amit a MiniBrowser nem szolgál ki nyit meg, más böngésző megnyitja korrektül? Ha nem, akkor az Apache/PHP beállítások áttekintését tudom javasolni, mint az előttem szóló is.

Szerk.: Valami hasonló van-e a httpd.conf-odban? 


LoadModule php5_module "/foo/bar/php5apache2_2.so"
AddType application/x-httpd-php .php

--
A gyors gondolat többet ér, mint a gyors mozdulat.

a PHP oldalt, amit a MiniBrowser nem szolgál ki nyit meg, más böngésző megnyitja korrektül?

Nos. Pontosan ez a helyzet. UBUNTU 8.04 op.rendszerem van. Két web böngésző is fel van telepítve (FireFox és Konqueror). Mindkettőben helyesen jelenik meg a PHP által generált oldal.

Egy példa:

Induljunk el erről az oldalról: http://jancsiweb.com/sfree/letoltesek.php?id=10353
Ha az egyik sorra rákattintunk, akkor válasszuk az ingyenes letöltést. A FireFox helyesen megjeleníti ekkor a letöltésre szolgáló oldalt, míg a MiniBrowser egy olyan oldalt jelenít meg, ahol azt közlik, hogy a kért állomány nem létezik. Természetesen a FireFox is ezt jeleníti meg, ha ténylegesen nincs meg a fájl. De a megadott esetben létezik, tehát a MiniBrowser nem képes rendesen kapcsolatot teremteni a PHP oldallal.

Valami hasonló van-e a httpd.conf-odban?

Rákerestem. Nincs ilyen fájl a gépemen.

Rákerestem. Nincs ilyen fájl a gépemen.

Mert nem a saját gépeden futó Apache+PHP szolgálja ki a böngésződet. Ne is keresd. :D

Megnéztem a példalinket, valószínű, hogy ez a MiniBrowser nem fogja megenni az ilyen redirect-es linkeket.

Szerk.:

Próbálj meg egy html állomány kreálni a saját gépeden az alábbi tartalommal: 


<html><head>
  <meta http-equiv="Refresh" content="5; url=http://www.hup.hu/">
</head><body>
  <p>5 másodperc múlva megyünk a HUP-ra!</p>
</body></html>

Ezt az állományt nyisd meg a böngészőben, és ha 5mp múlva nem kerülsz a HUP-ra, akkor ez is lehet egy ok.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

További érdekesség:

Ha a FireFox-ban megnyitom a kérdéses PHP oldalt, és a generált HTML fájlt lementem a saját könyvtáramba, akkor a lementett fájlt már meg lehet nyitni a MiniBrowser-vel.
Tehát nem magának a HTML fájl megjelenítésével van gondja, hanem ezt a HTML generálási folyamatot nem tudja jól követni.
Nem lehet valami olyasmi, hogy a szerver jelzi, mikor van kész az oldal, és ezt nem várja meg a MiniBrowser?

Azon gondolkodtam még, hogy a PHP oldal megjelenítésekor nem elég csupán az oldalt megjeleníteni, mint egy normál HTML fájl esetén, hanem közölnünk kellene, hogy melyik fájlt akarjuk letölteni. Tehát a böngészőnknek először meg kellene adnia, hogy az adott fájlt akarjuk letölteni, és a PHP ennek megfelelően generálná az oldalt.
Ez talán azért is valószínű, mert válaszként egy olyan oldalt kapunk, ami a fájl hiányát nyugtázza. Természetesen, ha nem kérünk semmit, arra nem is kapunk megfelelő válasz a PHP-től.
Elképzelhető, hogy ez az adatközlés hiányzik a PHP felé?

Egyre erdekesebb! :^D

Szerintem elso lepeskent nezz at egy HTTP protokoll leirast, hogy ne irj ekkora butasagokat. Aztan gondolkozz el azon, hogy bolcs otlet-e egy bongeszot egy relative primitiv HTML motorra alapozni, melyet valoszinuleg sugo oldalak meg hasonloan egyszeru dokumentumok megjelenitesere szantak!

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

meg nézd meg ezt, ez nekem rendesen lekezelte a hivatkozott oldalt.

Nálam a megadott "Simple" browser sem működik helyesen. Valami beállítási gond lehet a gépemen? (UBUNTU 8.04, JDK 1.6)

A Lobo jól működik.
Viszont nem találom sehogyan a Lobo forráskódját. Pedig nyílt forrásúnak emlegetik.

Viszont nem találom sehogyan a Lobo forráskódját. Pedig nyílt forrásúnak emlegetik.

Mert nem nézel körül... :/ Baloldalt, menü -> Source Code
Ott szépen le van írva, hogy hogyan kell Eclipse alatt CVS-ből lezúzni a kódot. Utána meg elolvasod a doksit itt és próbálsz önállósodni. :)

--
A gyors gondolat többet ér, mint a gyors mozdulat.

Ahogy fentebb írták, a böngészőnek halvány lila balsejtelme sem kell, hogy legyen arról, miként keletkezett a válaszként kapott HTML, tehát tök mindegy, hogy egy statikus file "felolvasásával" és visszaküldésével, vagy bármilyen program által generáltan, vagy akár a kis kínai gépeli be consol-on :) . Lehetséges okok:
- PHP valamiért rossz, vagy olyan HTML-t generált, amire nem vagy felkészülve. Csinálj egy olyan php file-t, amiben első körben csak statikus részek vannak, aztán fokozatosan tedd bele az echo, stb részeket. Itt kiderülhet, hol a bökkenő
- Valamiért eltérő content-type-al jön a válasz, amit nem kezelsz
- Valamiért kapsz olyan extra header-t, amit nem, vagy nem jól kezelsz.

Más különbséget nem nagyon tudok kigondolni.

Nekem van egy oldalam, ahol a html-t változókba gyűjtögetem, tehát nem szépen tabulálva meg minden, csak úgy masszaként. Minden böngészőben jól működik, kivéve a chrome-ot, ott az egyik input mező helyett néha ki van írva a kód fele. Frissítés után megjavul. A chrome gyors, csak nem pontos :) (Amúgy css műveletek esetében kifejezetten lassú)

( pelz | 2010. 02. 20., szo – 11:24 )

Nézegettem a PHP által generált HTML fájlt.

Ez van az elején: 


!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

Elképzelhető, hogy a Java még nem tud mit kezdeni ezzel a verzióval?

( golgota | 2010. 02. 20., szo – 13:08 )

Ez most komoly, hogy azt hiszed a php oldalt nem a webserver, hanem a webkliens generálja le????

( Nickname | 2010. 02. 21., v – 13:29 )

Ha túljutottál a php és apache configokon, meg a mime és egyéb csodákon, akkor jobb ha tudod, hogy ez a "Minibrowser" a java api JEditorPane-jét használja a renderelésre ami a default böngésződ renderjét használja natívan, tehát valójában semmi saját nincs itt csak egy java wrapper...

Ha tényleg "saját" böngészőt akarsz (java-ban), saját parser, js, css stb, akkor nézd meg ezt: http://lobobrowser.org/cobra/getting-started.jsp

Ezen akadtam ki en is. A java tudtommal nagyon minimalis kulso libre tamaszkodik, linux alatt gyakorlatilag az X meg az ALSA az egyetlen, amitol explicite fugg, es a Gtk es Nimbus temak fuggnek meg a Gtk libjeitol. Es ezzel el is ertunk a Java fuggoseglistajanak vegere, semmilyen brozertol meg ilyesmitol nem fugg. Illetve egyetlen esetben fugghet: ha kivalasztod, hogy plugint is akarsz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( pelz | 2010. 03. 08., h – 23:45 )

Arra a végeredményre jutottam, hogy a sütik nem elfogadása a magyarázat a dologra. Az egyszerű browser progik nem képesek a sütiket elfogadni. A letöltő oldal pedig vizsgálja (a sütik segítségével), hogy hogyan jutottál az adott oldalra. Ha nem úgy, ahogy azt ő szeretné, akkor nem enged letölteni, és ekkor egy olyan alapértelmezett oldalt dob, amin nincs letöltési lehetőség.

Ha tehát rá tudom venni a browser progimat, hogy kezelje a sütiket megoldódhat a feladat.