Geframede PHP pagina's doen raar in Firefox?

[RobertdeBruin]

Ik loop tegen een probleem aan bij Firefox:

Ik ben bezig met een site te ontwikkelen (PHP 4.3.7, Apache 2.0.3.4 op Windows XP Pro SP2). Deze bestaat uit een aantal frames waarin diverse PHP files worden geladen. Als ik de hele frameset refresh dan lijkt het random te gebeuren dat een van de frames niet geladen worden, en dat deze zelfs ter download aangeboden wordt door Firefox! Uiteraard is hij wel geparsed (dus geen broncode wordt aangeboden), maar de file bevat headers, zoals dit:

code:

0

HTTP/1.1 200 OK
Date: Fri, 04 Feb 2005 10:47:08 GMT
Server: Apache/2.0.43 (Win32)
X-Powered-By: PHP/4.3.7
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

211
‹      ´T[o›0~î¤ýÏ{Kœl«Ú¨€dŒ¬š‹Œ«(Oe^‚J N[þýl U¦©{Z^0çös¾cçS¹N)eÄAzïsF œ ´úJ
d0¾Mgs yÝ–ºlê¼BˆÆÐûøÁ±æþ¤80ç…#™äÔ‹ÝTÇ–›ísށ0~Vy(º¢R`h~Ý:hð·‘;¥s°Õz?Q¿Žå“ISkUë‰ìö
‚b\¨Õ‹F[½«n@±Í­ÒnÙ6“ëëËÅdêÁ8‹ï€ Ü…­î*Õn•ÒØVG€¢m!½uá}¯ò®9j´ËËzj-Ã4…Ʈ̯Ÿka±dqHÙ2”.œÁQ±b{YXË ìe™¤'’ŸH™D'
NoO½    ÇYæ‡*/{r%ö95a" bð œg)&,^¾É)‚Wy¬äj1â…ç˜bΖ&CaØS”X£XÆ^.¡ç°h   2A,å.ߨi;ñé¦üù§#’ýˆ÷SŒu|1e|®ÚýMc‰¼xß{>»2àxÊù8x3.i¸¢¦;&è‘$2m¬„½þ?‚,“‚ù÷2Ùy2¤‚fg‚–”„1#˜Ÿ>“•Ïî虪·O÷LÐ$‰%&òüŸø]à×kú§9n    »zå¸  ÿÿ 7I§¤V  
0

0

HTTP/1.1 200 OK
Date: Fri, 04 Feb 2005 10:47:08 GMT
Server: Apache/2.0.43 (Win32)
X-Powered-By: PHP/4.3.7
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 407
Keep-Alive: timeout=15, max=96
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1

‹      lRQOƒ0~ÖÄÿp61êÃèŒ>),a´b¤œ1{2Œá$â0P¢‹ñ¿ÛÓÅøÒÞw_¿ï®×ÚÇ,òpsð1ßOEàQúpéQʐõÄ•5¬ÓMS¨¢Ú¤%¥|N&G‡¶a»»Lï6(ø$¬TU¶àëç÷t~úþ&YgÛ¬Ìá­®Vm¦›öçRó;\8¤QÛ2ožó\0Í9DåŜfMCÀ—üÖ!},ÓmÕ*úšË0ÚC÷A‡Ft˜à¢wFf=e™×ð©ÑÁ2Í^ÖuÕnV£â5]çp
m]žZ´ƒ
]l/ÕúÊZO§ç7Zÿeªì¼u<Ø<á&&#8240;Czi&#8222;&#8230;¡+gÁÜ!c&#8218;ßâìCŸ3÷C¿ÃÒ0{Œâ_4±Ñ
®«HÆeÇ{\&#710;$v½`>ûÁ±ËØÎ:ÜU½Oº'D©
ÙŸ+Lì œA"=3ëa.Ê| 3&#710;ÿý´&#8224;"3&#8249;4¶´kRC3 .1ü&#8226;o   ÿÿ þEõìt  HTTP/1.1 304 Not Modified
Date: Fri, 04 Feb 2005 10:47:08 GMT
Server: Apache/2.0.43 (Win32)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=95
ETag: "639b-1e4-e0f21966"

Vreemd genoeg zie je ook dat de headers 3x herhaald worden.

Nu gebruik ik ook PHP's output buffering (ob_gzhandler). Zet ik deze uit, dan wordt het bestand niet ter download aangeboden, maar wordt deze output gelijk in het frame getoond.

Refresh ik weer, dan is er een kans dat alles het gewoon doet, of dat een ander frame dit probleem geeft.

Ik heb deze problemen echter niet als:
- Ze online geplaatst zijn (andere hosting)
- Onder Internet Explorer
- Als ze niet in een frame worden geladen!!!

Internet/GOT geven nog geen verheldering, misschien dat iemand iets weet? Ik zit zelf te denken aan PHP/Apache, maar ik zou niet weten waar ik iets als dit moet kunnen vinden in de configfiles. Vooral dat punt van wel/niet in een frame geladen zijn vind ik echt raar. Ben benieuwd naar evt. oplossingen.

<edit>typo's</edit>

[ Voor 8% gewijzigd door RobertdeBruin op 04-02-2005 13:59 ]

[LuCarD]

Whiplash schreef op vrijdag 04 februari 2005 @ 12:02:
Ik loop tegen een probleem aan bij Firefox:

Ik ben bezig met een site te ontwikkelen (PHP 3.4.7, Apache 2.0.3.4 op Windows XP Pro SP2). Deze bestaat uit een aantal frames waarin diverse PHP files worden geladen. Als ik de hele frameset refresh dan lijkt het random te gebeuren dat een van de frames niet geladen worden, en dat deze zelfs ter download aangeboden wordt door Firefox! Uiteraard is hij wel geparsed (dus geen broncode wordt aangeboden), maar de file bevat headers, zoals dit:

Misschien een gekke vraag maar he PHP 3 ???? Wordt dat wel ondersteunt door Apache 2?

laat maar, je hebt PHP 4.3.7 en niet PHP 3.4.7... ( volgens je headers )

Wat gebeurt als je de frame pagina los op roept?

[ Voor 9% gewijzigd door LuCarD op 04-02-2005 13:02 ]

[Zoefff]

Volgens mij word PHP3 wel ondersteund door Apache, maar het lijkt me sowieso wel een goed idee om je PHP versie te upgraden

Laat maar dus, je hebt 4.3.7 ipv 3.4.7

[ Voor 17% gewijzigd door Zoefff op 04-02-2005 13:04 ]

[FendtVario]

Gaat er niet iets fout met de GZIP encoding? Probeer die eens uit te zetten en probeer dan nog een keer.

[RobertdeBruin]

LuCarD schreef op vrijdag 04 februari 2005 @ 13:01:
[...]

Wat gebeurt als je de frame pagina los op roept?

Dat isdus het gekke, dan doet hij het zonder problemen!

FendtVario schreef op vrijdag 04 februari 2005 @ 13:10:
Gaat er niet iets fout met de GZIP encoding? Probeer die eens uit te zetten en probeer dan nog een keer.

Als ik dat doe, dan toont hij die headers in het frame zet (niet als download). Alsnog niet goed dus. Er zit wel een verschil tussen beide outputs

Met gzip, Firefox downloadde deze als een los bestand (alsof je een binairy aanklikt)

code:

0

HTTP/1.1 200 OK
Date: Fri, 04 Feb 2005 13:04:54 GMT
Server: Apache/2.0.43 (Win32)
X-Powered-By: PHP/4.3.7
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=96
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

1d9
&#8249;      |RÑjÛ0}Þ`ÿ i¬Ilyl&#402;.µIìÆfN2Fª¢ÄnmË&#8220;ä6¦äßgɤy&#732;$Ð=çÜ+Ý&#402;ä¾÷&#8220;Þ¬âEV?§q4ÐBèöó!ûðÅv ¤&#8221;&#8482;ÊxIr&#8222;&#8218;%¼~÷ÖÕªÙ&#402;&#8240;ßîo\á8¸^pÅóú ÂlŸ>&#8220;&#8222;äùhRÐ&#8224;æT&#8218;okª¤&#8249;º|]GËï`Ä&#8221;ªÉ&#8482;LSèæ<¨ØA!*%á:¸ñ ~ç¤áµBÉJ[+æŒ&#8218;)R¥*&#8249;ý©³'Îx©X©,ÜTÚ¡þ¼Tù )&#8217;)/&#8220;ܺ¼üúÍúÒ&#8211;PïIO÷Þ&#732;6§&#8240;¿/íU÷&#8222;>î¯Ë­EyÎÅ|p̸z-fÙ30µÈ&#8225;(Ñ}¯îDÛ&#8216;ýPí£³:¢¡iÑvÛï²Ûž%T¼{ŒVv>¶ëL¬bD×&#8211;¼uÂQ&#8250;9jsÿµ±ñ´&#732;¬çÑ2¢y&#710;=èÀž¸|¼ÖJGŒ&#8220;Õ    š&'&#8249;"nN³&#8220;eœL|>'"©È*5~ÉvÃŜ&#710;Ö¡½¤`ò&#8212;swqñš(^&#8482;ppgÏùèâpt4?i;Ýûuó/   ÿÿ Ð`wJä  
0

(wordt drie keer herhaald, de keep-alive gaat dan omlaag, van 96 > 95 > 94... (misschien is dit iets?)

Zonder Gzip, deze output wordt dan in een frame getoond

code:

0

HTTP/1.1 200 OK
Date: Fri, 04 Feb 2005 13:05:48 GMT
Server: Apache/2.0.43 (Win32)
X-Powered-By: PHP/4.3.7
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

2e4
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
    <TITLE>Motolux Highway Hawk Motorcycle products</TITLE>
    <LINK REL="stylesheet" TYPE="text/css" HREF="./_layout/main.css">
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</HEAD>


<STYLE>
BODY {
    background-color: #000000;
    background-image : url('./images/bground-front.jpg');
    background-attachment : fixed;
    background-position : 0% 0%;
    background-repeat : no-repeat;
    }

}
</STYLE>

<BODY MARGINHEIGHT="0" MARGINWIDTH="0" RIGHTMARGIN="0" TOPMARGIN="0" BOTTOMMARGIN="0" LEFTMARGIN="0" ONLOAD="javascript:{if(parent.frames[0]&&parent.frames['topframe'].Go)parent.frames['topframe'].Go()}">
</BODY>
</HTML>

0

0

HTTP/1.1 200 OK
Date: Fri, 04 Feb 2005 13:05:48 GMT
Server: Apache/2.0.43 (Win32)
X-Powered-By: PHP/4.3.7
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

211

Wie het weet mag het zeggen :-).

[FendtVario]

Is het bestand waar de frames in staan ook een PHP bestand? Wat is je code hiervan, het lijkt erop dat er in je output geen frames zitten (in zie inbovenstaande code geen frameset of iets dergelijks) het ziet er meer uit als je alle pagina's onder elkaar zet en die naar de browser stuurt.

[frickY]

Ik heb in ieder geval gemerkt dat FireFox echt nauwkeurig is als het op mime-types aankomt, in tegenstelling tot IE.
Ik denk dat er iets misgaat met de "Content-type" header, waardoor Friefox het bestand niet als html intepreteerd, en hem probeerd te parsen. Zet eens boveaan je PHP-scripts

PHP:

header("Content-type: text/html");

om te zien of dat iets oplost..

Als dat het oplost is het een configuratiefout van je Apache-server, waardoor PHP's niet als text/html worden geserveerd.
Het is overigens wel uiterst vreemd dat hij het willekeurig doet, en alelen indien ze in een frame geladen zijn.

[ Voor 35% gewijzigd door frickY op 04-02-2005 14:27 ]

[FendtVario]

Als je naar de headers kijkt zie je dat er al 3x een Content-type in zit. Ik weet niet of het zo hoort dat charset daar direct achter staat.

[RobertdeBruin]

FendtVario schreef op vrijdag 04 februari 2005 @ 14:13:
Is het bestand waar de frames in staan ook een PHP bestand? Wat is je code hiervan, het lijkt erop dat er in je output geen frames zitten (in zie inbovenstaande code geen frameset of iets dergelijks) het ziet er meer uit als je alle pagina's onder elkaar zet en die naar de browser stuurt.

code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
    <TITLE><? echo $ucfg_site_title; ?></TITLE>
</HEAD>

<diverse functies... knip>

<!-- frames -->
<FRAMESET COLS="*,790,*" BORDER="0" FRAMESPACING="0" FRAMEBORDER="0">
    <FRAME NAME="filler1" SRC="misc-filler.php" MARGINWIDTH="0" MARGINHEIGHT="0" SCROLLING="no" FRAMEBORDER="no" FRAMESPACING="0">

    <FRAMESET ROWS="126,*,30" BORDER="0" FRAMEBORDER="0" FRAMESPACING="0">
        <FRAME NAME="topframe" SRC="misc-top.php" MARGINWIDTH="0" MARGINHEIGHT="0" SCROLLING="no" FRAMEBORDER="0" FRAMESPACING="0">
        <FRAME NAME="main" SRC="<? echo $address; ?>" MARGINWIDTH="0" MARGINHEIGHT="0" SCROLLING="auto" FRAMEBORDER="0" FRAMESPACING="0">
        <FRAME NAME="nav" SRC="alg-contents.php" MARGINWIDTH="0" MARGINHEIGHT="0" SCROLLING="no" FRAMEBORDER="0" FRAMESPACING="0" NORESIZE>
    </FRAMESET>

    <FRAME NAME="filler2" SRC="misc-filler-stats.php" MARGINWIDTH="0" MARGINHEIGHT="0" SCROLLING="no" FRAMEBORDER="no" FRAMESPACING="0">
</FRAMESET>
<BODY>

</BODY>
</HTML>

Ik toonde eerder alleen de output van een 'falend' frame, maar een frameset makendat doe ik wel eens vaker .

frickY schreef op vrijdag 04 februari 2005 @ 14:25:
Ik heb in ieder geval gemerkt dat FireFox echt nauwkeurig is als het op mime-types aankomt, in tegenstelling tot IE.
Ik denk dat er iets misgaat met de "Content-type" header, waardoor Friefox het bestand niet als html intepreteerd, en hem probeerd te parsen. Zet eens boveaan je PHP-scripts

PHP:

header("Content-type: text/html");

om te zien of dat iets oplost..

Als dat het oplost is het een configuratiefout van je Apache-server, waardoor PHP's niet als text/html worden geserveerd.
Het is overigens wel uiterst vreemd dat hij het willekeurig doet, en alelen indien ze in een frame geladen zijn.

Ik heb jouw voorbeeld even gevolgd, want je oplossing klinkt toepasselijk. Helaas maakt het niets uit, ook niet voor de uiteindelijke inhoud van de vage pagina's. Het is ook echt random: iedere refresh (zonder dat ik tussendoor iets wijzig), kan voor andere effecten zorgen. Ik heb de cache van Firefox al leeggehaald, PHP 4.3.10 geinstalleerd. Misschien nu maar even een andere apache proberen.

[TheDane]

heb je al in de errorlogs van apache gekeken?
Ik heb zelf "ook zoiets" gehad; bij mij lag 't aan de initialisatie van een sessie die in frameset niet goed gedaan werd, en 'standalone' wel. In de errorlogs zag in bij de frameversie allerlei nieuwe warnings en errors.

it's a long shot, maar misschien heb je d'r wat aan.

[RobertdeBruin]

Nou, het probleem is verholpen, maar het hoe&waarom is mij nog niet helemaal duidelijk.

Er stond niets in de errorlogs, maar het leek mij bijna zeker bij Apache te liggen (zeker omdat ik php al had vervangen). Daarom 2.0.52 geinstalleerd. Hier bleek alles te werken.
Ik heb een compare op de httpd.conf uitgevoerd.

Oude configfile

code:

AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

Nieuwe configfile

code:

# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+) uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
#AddEncoding x-compress .Z
#AddEncoding x-gzip .gz .tgz
#
# If the AddEncoding directives above are commented-out, then you
# probably should define those extensions to indicate media types:
#
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz

Lijkt op zich dan wel logisch, geen compression dus in de nieuwe config. Ik heb toen de moeite genomen om deze instellingen in mijn oude installatie aan te brengen en deze weer te draaien, maar de problemen waren desalniettemin aanwezig! Ik kan dus niet met zekerheid zeggen dat het aan dit verschil ligt. Misschien nieuwe code in apache zelf? In ieder geval heb ik het ook andersom getest, in de nieuwe configfile de instellingen voor x-compress en x-gzip overgenomen... en alles werkt nog gewoon (dan ligt probleem dus vrijwel zeker ergens anders).

In ieder geval bedankt voor alle snelle feedback.

[Battle Bunny]

Zou het kunnen zijn dat je HTTP pipelining aan hebt in Firefox? Ik weet even bij God niet meer waar ze dat hebben verstopt, maar er zijn problemen bekent met FF icm bepaalde webservers (of ging dat om IIS?)

[André]

Battle_Bunny schreef op vrijdag 04 februari 2005 @ 16:07:
Zou het kunnen zijn dat je HTTP pipelining aan hebt in Firefox? Ik weet even bij God niet meer waar ze dat hebben verstopt, maar er zijn problemen bekent met FF icm bepaalde webservers (of ging dat om IIS?)

Volgens mij onder: about:config

[FendtVario]

http://www.mozilla.org/pr.../http/pipelining-faq.html

[frickY]

Shit dat ik dat niet meteen zag;

code:

Keep-Alive: timeout=15, max=98
Connection: Keep-Alive

Hij trekt alle pagina's over 1 pipeline binnen. Dat is zowieso iets wat IE niet kan (ookal is het een HTTP1.1 standaard). Daarom zie je de headers 3x, het zijn ook 3 paginas die hij binnen haalt. Hij kan ze alleen niet goed splitten.

[ Voor 3% gewijzigd door frickY op 04-02-2005 16:23 ]