[HTML/PHP] html frame cache

[Sebastiaan11]

De titel klinkt als een veel herhaalde kwelling en helaas is het mij nog niet gelukt deze kwelling te verdrijven.

Ik ben een CMS aan het bouwen, waarbij ik statische HTML pagina's genereer. Het CMS laadt de html-pagina's in een frame, en een javascript functie in het overkoepelende bestand frames.php (met daarin frameset) plakt events aan elementen in de html-pagina's die in het frame worden ingeladen.

Het CMS werkt als een zonnetje, met maar 1 duistere zwarte wolk die zeer bepalend is voor de usability; de aangepaste statische html files lijken de cache van webbrowser niet te kunnen omzeilen en tonen de oude html files, in plaats van de zojuist gegenereerde html files.

Ik heb flink gegoogled en heb verschillende oplossingen voorbij zien komen. Helaas blijken deze oplossingen verouderd, of niet geschikt voor standaard hosting.

---

Ik heb het volgende geprobeerd in de statische html files:

• Verscheidene soorten van meta tags, te weten:
  
  code:
  

     <meta http-equiv="pragma" content="no-cache">
     <meta http-equiv="cache-control" content="no-cache">
     <meta http-equiv="expires" content="-1">
     <meta name="Build" content="2008-04-06 20:04:34" >

• Gebruik van .htaccess headers voor cache control, maar deze worden niet ondersteund door de meeste hosting bedrijven en leveren daarom enkel een foutmelding op.

---

Het volgende heb ik geprobeerd in frames.php file (met daarin de frameset en dus ook het frame waarin de html files worden ingeladen):

• Alle bovenstaande meta tags
• PHP header (maar deze heeft blijkbaar -zoals verwacht- alleen invloed op code in frames.php, en niet op de files die worden ingeladen in de frameset)

code:

   header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

---

Met javascript in de frames.php heb ik het ook geprobeerd:

• Koppelen van 'junk' aan de url, zodat deze uniek zou moeten zijn:
  
  code:
  

     frames[0].window.location = "../"+url_location+"?junk="+(new Date()).valueOf();

  
  Middels javascript reloaden (lelijke oplossing -> knop die refreshed door de huidige url te verrijken met de junk tail) lijkt te werken, maar wanneer er weer genavigeerd wordt middels links in de html pagina's worden de oorspronkelijke -verouderde- html pagina's getoond. Om nu bij elke page load (opgevangen in frames.php) de url op te halen, junk tail te plakken, en opnieuw te laden lijkt me te veel van het goede. Tevens zal de 'oude' html getoond worden op de site van de gebruiker wanneer het CMS wordt verlaten.

Is er iemand die mij een hint of oplossing kan geven zodat ik de webbrowser cache kan omzeilen en volledig gebruik kan maken van de statische html structuur?

[McKaamos]

quote: http://www.web-caching.com/mnot_tutorial/how.html

Meta tags are easy to use, but aren't very effective. That's because they're usually only honored by browser caches (which actually read the HTML), not proxy caches (which almost never read the HTML in the document). While it may be tempting to slap a Pragma: no-cache meta tag on a home page, it won't necessarily cause it to be kept fresh, if it goes through a shared cache.

Gezien je in je topictitel aangeeft PHP te kunnen gebruiken, zou je een HTTP header kunnen mee sturen dmv php.
Als je controle hebt over .htaccess zou je daar een paar regels in kunnen zetten die html files laten parsen door PHP, zodat je bovenin je htmll een stukje code zoals dit kan zetten:

PHP:

<?php
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
?>

//je HTML document

en in je htaccess dit:

code:

AddType application/x-httpd-php .php .htm .html

Het effect is dat je cache control informatie nu in de HTTP header staat ipv in je HTML document en dus ook door proxy's e.d. wordt gehonoreerd.
Dat levert op dat je documentjes dus niet gecached worden.

editje:
Als je met htaccess niks kan, kan je je html documentjes ook opslaan als php en dan gewoon geen php code er in prakken. Dan worden ze wel geparsed door PHP. Mik dan je header info er in, en het zou ook moeten werken.

edit2: oh, en met die laatste optie: php files worden van zichzelf minder snel gecached, want browsers en proxies herkennen de extensie als dynamische content files. Nadeel is dan wel weer de vindbaarheid in Google (want die reageert daar ook op.)
Het opslaan met de extensie php levert in dat geval geen security risico op, gezien er geen PHP code gebruikt wordt (alleen de header informatie, geen variabelen oid waar stiekem een code injectie in gestopt kan worden)

[ Voor 37% gewijzigd door McKaamos op 07-04-2008 22:51 ]

[Sebastiaan11]

Ontzettend bedankt McKaamos,

De vindbaarheid in google is de voornaamste reden dat ik gekozen heb voor static html.

Ik kan gebruik maken van de .htaccess functies. Lokaal en bij hosting A werkt dit uitstekend (html files bovenaan aanvullen met php code).

Bij hosting B gaat de vlieger niet op: Ik heb nu niet de juiste permissies meer om de html files te overschrijven. Heb je enig idee hoe ik dit kan verhelpen? Wellicht een aanvulling op de .htaccess?

[McKaamos]

Probeer die AddType regel eens toe te voegen aan je html document en dan phpinfo() op te vragen in een html file? Kijk eens offie dat lust.
Alssie het lust kan je html als php laten parsen.

Edit: bedoel je daadwerkelijk de files overschrijven? rechten al op 775 geprobeerd? CHMOD via een FTP progsel? en je FTP progsel in passive mode?

[ Voor 28% gewijzigd door McKaamos op 08-04-2008 00:19 ]

[Noork]

Sebastiaan11 schreef op maandag 07 april 2008 @ 23:34:
De vindbaarheid in google is de voornaamste reden dat ik gekozen heb voor static html.

Leg eens uit? De meeste database/cms aangedreven sites zijn prima te vinden in google

[Verwijderd]

Sebastiaan11 schreef op maandag 07 april 2008 @ 23:34:
De vindbaarheid in google is de voornaamste reden dat ik gekozen heb voor static html.

Je weet dat de geserveerde bestandsnaam niets te maken heeft met de daadwerkelijke bestandsnaam?

[curry684]

Sebastiaan11 schreef op maandag 07 april 2008 @ 23:34:
De vindbaarheid in google is de voornaamste reden dat ik gekozen heb voor static html.

Je weet dat naast de 2 punten hierboven je site juist slechter vindbaar wordt als je afhankelijk gaat zijn van Javascript voor goed tonen?

[Sebastiaan11]

@ McKaanos: De html file wordt gelezen als zijnde php, dat gaat goed. Probleem is dat ik in eerste instantie de html files kon overschrijven, dat lijkt nu niet meer te lukken. Wanneer ik de 'php' eigenschap verwijder kan ik de files wel overschrijven. Misschien is dit ook wel ingesteld bij de hosting partij... Ik ben op de hoogte van permissie structuur.

@ Noork: Ik heb gekozen voor static html (soort nu.nl html-structuur) waarbij content statisch aanwezig is. Dit heeft enkele voordelen:
- Html kan beter gelezen worden door spiders door statische structuur.
- Systeem hoeft geen gebruik te maken van meerdere bestanden, database aanroepen of javascript: naar mijn mening de snelst mogelijke en degelijke manier. Basic html.

@ TRRoads: Check

@ Curry684: Jep, de javascript wordt alleen gebruikt voor binnen het CMS (dom tree reader, event attacher, etc). De website zelf bestaat enkel uit geparste html (aangevuld waar nodig met ajax voor speciale modules die een database vereisen).

Een oplossing zou naar mijn mening de mooiste vorm hebben als ik een .htaccess file zou kunnen toevoegen waarin ik de cache control kan beheren. Zoals bovenstaand vermeld, heb ik geen rechten op de servers van de hosting partijen voor header control binnen .htaccess. Ook zou het een mooie oplossing zijn als ik binnen de frames.php de cache control van de onderliggende frames zou kunnen beheren.

[McKaamos]

Sebastiaan11 schreef op dinsdag 08 april 2008 @ 09:35:
@ McKaanos: De html file wordt gelezen als zijnde php, dat gaat goed. Probleem is dat ik in eerste instantie de html files kon overschrijven, dat lijkt nu niet meer te lukken. Wanneer ik de 'php' eigenschap verwijder kan ik de files wel overschrijven. Misschien is dit ook wel ingesteld bij de hosting partij... Ik ben op de hoogte van permissie structuur.

Misschien een omweg, maar zou je die html files misschien een extra waarde kunnen opgeven door b.v. een .txt file in te lezen via php code? Die wordt dan uitgespuugd als de HTML code.
Wss kan je een plain text file wel editten.

[André]

Sebastiaan11 schreef op maandag 07 april 2008 @ 23:34:
De vindbaarheid in google is de voornaamste reden dat ik gekozen heb voor static html.

Dit is onzin. Je kunt een server zo instellen dat .html bestanden als .php bestanden gezien worden. Op die manier kun je php gebruiken in .html bestanden. Aangezien Google dit ook weet doen ze helemaal niets met de extensie. Daarnaast is het zo dat wat je ook gebruikt er altijd HTML naar de browser gestuurd wordt.

[Sebastiaan11]

Misschien een omweg, maar zou je die html files misschien een extra waarde kunnen opgeven door b.v. een .txt file in te lezen via php code? Die wordt dan uitgespuugd als de HTML code.
Wss kan je een plain text file wel editten.

Hierbij is het idee van een statische file weg: De file moet nu een andere file inlezen, en is in zekere zin dynamisch.

[Sebastiaan11]

Dit is onzin. Je kunt een server zo instellen dat .html bestanden als .php bestanden gezien worden. Op die manier kun je php gebruiken in .html bestanden. Aangezien Google dit ook weet doen ze helemaal niets met de extensie. Daarnaast is het zo dat wat je ook gebruikt er altijd HTML naar de browser gestuurd wordt.

Ok, de extensie is onafhankelijk van 'succes'. Toch lijkt het me zinvol dat een file statisch is; een file hoeft niet te parsen of database aanroepen te doen. Tevens krijgt een spider dezelfde pagina te zien ongeacht de get variabelen die worden meegestuurd (get variabelen zijn overbodig in static html). Dit lijkt me de 'vindbaarheid' ten goede komen.

[Janoz]

Het enige steekhoudende argument is misschien de get parameters, maar daarvoor zijn legio andere manieren. Neem als voorbeeld de frontpage van tweakers. Allemaal URL's met daarin titel_van_item.html. Geen get parameters, maar denk maar niet dat het allemaal statische pagina's zijn die Femme vliegensvlug loopt te copy pasten.

Als je je zo druk maakt over searchengine friendlyness, waarom gebruik je dan uberhaupt frames? Niet alleen maakt dat het spyderen lastig, bezoekers komen ook op compleet onwerkbare resultaten uit.

[Sebastiaan11]

Janoz schreef op dinsdag 08 april 2008 @ 10:27:
Als je je zo druk maakt over searchengine friendlyness, waarom gebruik je dan uberhaupt frames? Niet alleen maakt dat het spyderen lastig, bezoekers komen ook op compleet onwerkbare resultaten uit.

De frames worden alleen gebruik aan de kant van het CMS, niet aan de kant van de 'website'. De website wordt ingeladen in een frame van het CMS (de overige frames bestaan uit 'toolbars'). Uiteraard wil ik de standaard bezoekers niet opschepen met een frame-based website!

Met deze opstelling is het mogelijk voor de CMS gebruiker om de website te editen volgens het What You See Is Realy What You Get principe. Alleen moet dat wel het cache probleem opgelost worden...

[ Voor 15% gewijzigd door Sebastiaan11 op 08-04-2008 10:34 ]

[curry684]

Sebastiaan11 schreef op dinsdag 08 april 2008 @ 09:35:
@ Noork: Ik heb gekozen voor static html (soort nu.nl html-structuur) waarbij content statisch aanwezig is. Dit heeft enkele voordelen:
- Html kan beter gelezen worden door spiders door statische structuur.

En jij dacht dat er op nu.nl ook maar 1 regel statische HTML stond? Of hier? Of hier?

- Systeem hoeft geen gebruik te maken van meerdere bestanden, database aanroepen of javascript: naar mijn mening de snelst mogelijke en degelijke manier. Basic html.

Cached HTML pagina's genereren was leuk toen de 486's nog op stoom liepen. Tegenwoordig in het tijdperk van multigigahertz quadcores zijn de nadelen als achterlopende content en gebrek aan dynamische elementen waar ze keihard nodig zijn ver groter dan de twijfelachtige voordelen. Ik heb webservers die meer dan 10Mbit per seconde volcontinu verstouwen en nog steeds de 5% CPU usage zelden aantikken.

[alex3305]

Als een database en dergelijke zulke moeilijke resultaten opleverd in Google en dergelijke, waarom zijn 99% van de grote sites dan uitgevoerd in dynamische content. Daarnaast zijn standaard platformen zoals WordPress, Joomla, Drupal en vele anderen allemaal dynamisch.

Daarnaast heeft Janoz helemaal gelijk in verband met frames. Het is namelijk niet vriendelijk voor de gebruiker en voor search engines en doorlinken naar een enkele pagina gaat al helemaal niet goed! Geef mij maar een dynamische pagina dan

offtopic:
Het is really

[McKaamos]

Alex, hij zegt al dat het frame puur voor het beheer systeem is de website zelf is frameloos.

Als het puur voor het beheer gedeelte is, kan je dan niet met een php file werken die een html file inleest en vooraf laat gaan door een no cache HTTP header?
Iets als /cms/preview.php?file=frontpage.html en dan in preview.php zoiets als dit:

PHP:

<?php
header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");

$htmlfile = fopen($_GET['file'], r);
$contents = fread($htmlfile, filesize($_GET['file']));
fclose($htmlfile);

echo $contents;
?> 

Dat de users van de site pagina's cachen zou verder niks uit mogen maken, die refreshen maar een paar keer ofzo. De admin moet wel altijd de correcte data te zien krijgen.

Edit: dit is wel heel vies gedaan trouwens, heel gevoelig voor code injectie, maar als het achter een beveiliging zit kan het niet zo heel veel kwaad. En uiteraard mag je er nog wel wat checks aan toevoegen (b.v. in de vorm van een regex testje die checkt of het wel een valid filename is)
Dus niet rechtstreeks zo van mijn voorbeeld overnemen in je productie omgeving

Edit2:
Met Bozozo onder mij

[ Voor 19% gewijzigd door McKaamos op 08-04-2008 11:33 ]

[Bozozo]

Ik zie het voordeel van statische webpagina's ook wel hoor. Uiteindelijk zal het toch echt een fractie sneller zijn dan query + verwerken. Het lijkt me ook de allerveiligste manier om een website op te zetten (er valt weinig te hacken aan een mapje html bestanden).

Zelfs voor statische pagina's die redelijk vaak worden geüpdate zou het schrijven van nieuwe html files met PHP een optie zijn. Je kunt alles analoog doen aan de dynamische manier (dwz een database bijhouden op de server en een via het web toegankelijk CMS gebruiken / maken) met één extra knopje "Apply Changes" dat nieuwe HTML files schrijft.

Het wordt natuurlijk wel een beetje lastig als je met AJAX elke minuut nieuwe nieuwsberichtjes door het beeld wilt laten zoeven en dat soort fratsen, maar er zijn genoeg sites met alleen enkele tientallen pagina's informatie die eens in de maand een klein beetje worden aangepast.

PS: Als je de url's serverside een beetje handig verwerkt kan een gebruiker / spider volgens mij het verschil tussen statische en dynamische pagina's helemaal niet zien.

PPS: Het valt me op (niet in het bijzonder in dit topic overigens) dat zodra iemand eens iets anders wil doen dan anders, er veel negatieve reacties volgen in de trant van 'waarom opnieuw het wiel uitvinden' en 'gebruik gewoon library x, die werkt super'. Ik vind het juist prijzenswaardig als iemand zijn best doet om iets unieks te produceren. Dat leidt tot meer variatie op het web (ik word er zo onderhand erg moe van als ik Joomla + Mootools + Lightbox website 91.342.943 voorbij zie komen) en het is nog veiliger ook; denk aan sites als milw0rm waar regelmatig hacks voor bekende CMSen worden uitgebracht.

[Sebastiaan11]

De websites die ik oplever behoeven geen uiteenlopende dynamische content die vereist is bij nieuws-websites. Nu.nl is dan ook geen representatief voorbeeld (*zoekt smile met ezel-muts*).

Alex3305 schreef op dinsdag 08 april 2008 @ 10:57:
Als een database en dergelijke zulke moeilijke resultaten opleverd in Google en dergelijke, waarom zijn 99% van de grote sites dan uitgevoerd in dynamische content. Daarnaast zijn standaard platformen zoals WordPress, Joomla, Drupal en vele anderen allemaal dynamisch.

Dat een groot aantal -grote- sites dynamische content gebruiken vind ik zeker niet verwonderlijk, maar dat wil niet zeggen dat er nagedacht kan worden over optimalisatie van content representatie (zeker wanneer dynamiek niet vereist is). Ik heb zelf een aantal template engines gebruikt (o.a. Smarty) voor eerdere versies van het CMS, maar deze heb ik aan de kant geschoven omdat ik de ervaring heb dat het wel degelijk ten koste gaat van snelheid en 'statische aard' van representatie (...maar ongetwijfeld zijn de 'grote jongens' efficiënter opgezet).

@ Curry684: De hardware zorgt steeds minder vaak voor beperkingen, maar helaas is het nog niet mogelijk om bij de standaard hosting partijen optimale performance te verwachten. Wanneer een site geoptimaliseerd is zal de site meer bezoekers tevreden kunnen stellen door beperking aan load (zowel data als 'reken'-load).

Nogmaals: De frames worden alleen gebruikt binnen de CMS-admin. De site zelf maakt geen gebruik van frames.

Edit: Excuses voor traagheid bij het typen van response...

[Janoz]

Het is heel goed mogelijk dat een in memory template implementatie waarin content uit een database wordt gebruikt waarbij de output vervolgens ge-gziped naar de client gestuurd wordt een stuk efficienter werkt dan elke pagina weer van de hardeschijf inlezen en naar de client te sturen. Bedenk dat in servers de IO over het algemeen de grootste bottleneck is.

[Sebastiaan11]

McKaamos schreef op dinsdag 08 april 2008 @ 11:26:

//code

Als het puur voor het beheer gedeelte is, kan je dan niet met een php file werken die een html file inleest en vooraf laat gaan door een no cache HTTP header?

Dat de users van de site pagina's cachen zou verder niks uit mogen maken, die refreshen maar een paar keer ofzo. De admin moet wel altijd de correcte data te zien krijgen.

Het inlezen van de html in de php zou een optie zijn, als ik niet de complete navigatie mogelijkheden van de website zou willen behouden (wanneer wordt 'ingelezen' door php, werken de statische html links niet meer...). Is het niet op een of andere manier mogelijk om controle te krijgen over de headers van de html website die wordt ingeladen in het frame, vanuit de frames.php pagina? Als zijnde het injecteren (cache omzeilen) van de header binnen een frame?