[PHP]Cache 'forceren' voor dynamische css file

[Cartman!]

Ik ben bezig met een methode waarbij ik via een controller (Zend Framework) met 1 request al mn css files opvraag en strip van onnodige data (whitespaces, tabs, comments etc). Dit werkt helemaal geweldig op 1 ding na: de file wordt niet gecached door de browser.

Ik heb fullpage cache werken met Zend_Cache maar dat helpt niet zoveel, ja..aan serverload maar niet aan de client kant want hij krijgt een 200, OK header mee ipv. 304 Not modified. Wat ik wil is dus dit: de fullpage cache niet laten gelden voor de controller die de css file genereert maar dan vervolgens de juiste headers meesturen zodat de client deze gaat cachen.

Wat heb ik geprobeerd?
- Expires header op 5 maanden vooruit zetten, helpt niet

- ETag header opgeven met md5 hash van de data, werkt niet omdat de client die Etag gaat valideren en de webserver kent hem niet, dus roept ie de controller weer aan die dan weer netjes dezelfde ETag genereert...

- Cache-Control:public en private, maakt geen verschil

- Content-Length stuur ik mee

Het is vast heel simpel maar zoek me er helemaal stuk op. Welke headers kan ik nu het best aangeven zodat mn browser denkt: "hey...das statische content die ik kan cachen! :)"

[Rekcor]

Heb je hier iets aan? http://www.badpenguin.org/docs/php-cache.html Denk het niet, nu ik lees wat je zelf geprobeerd hebt .

Of misschien wel:

The Cache-Control HTTP Headers is part of the HTTP 1.1 standard. Here you are an example:

Cache-Control: max-age=3600, must-revalidate

It has a certain number of parameters that can be used:

* max-age=seconds - the number of seconds from the time of the request you wish this objcet to be keep into the cache;
* s-maxage=seconds - like max-age but it only applies to proxy;
* public - tell to handle the content has cacheable even if it would normally be uncacheable, it is used for example for authenticated pages;
* no-cache - force both proxy and browser to validate the document before to provide a cached copy;
* must-revalidate - tell the browser to obey to any information you give them about a webpage;
* proxy-revalidate - like must-revalidate but applies to proxy;

[ Voor 108% gewijzigd door Rekcor op 16-07-2008 16:20 ]

[Cartman!]

Ja, sorry... de max-age heb ik geprobeerd ook. In veel artikelen werd dat afgeraden.

[crisp]

Expires of max-age (zonder must-revalidate) zouden toch moeten werken voor 'soft-refreshes', voor gewone en hard refreshes (F5, ctrl+F5) wordt er toch een roundtrip gedaan naar de server en zal je voor dynamische content toch echt zelf iets moeten doen met de door de client meegestuurde If-Modified-Since...

[orf]

Op php.net (view source) staat dit voorbeeldje:

PHP:

$timestamps[] = @filemtime("include/pregen-events.inc");
$timestamps[] = @filemtime("include/pregen-confs.inc");
$timestamps[] = @filemtime("include/pregen-news.inc");
$timestamps[] = @filemtime("include/version.inc");

// The latest of these modification dates is our real Last-Modified date
$timestamp = max($timestamps);

// Note that this is not a RFC 822 date (the tz is always GMT)
$tsstring = gmdate("D, d M Y H:i:s ", $timestamp) . "GMT";

// Check if the client has the same page cached
if (isset($_SERVER["HTTP_IF_MODIFIED_SINCE"]) &&
    ($_SERVER["HTTP_IF_MODIFIED_SINCE"] == $tsstring)) {
    header("HTTP/1.1 304 Not Modified");
    exit();
} else {
    header("Last-Modified: " . $tsstring);
}

[Cartman!]

Ik test de hele tijd met F5 inderdaad, misschien is dat het dan

Overigens wil Zend_Cache ineens mn content-type niet meer onthouden voor cachepagina's en net wel, zwaar klote

[Gomez12]

Uberhaupt niet met F5 controleren. Controleer het gewoon door of in je url-balk op enter te drukken of maak gewoon een hyperlink op je eigen pagina...

Maar expire-dates meegeven vind ik altijd super werken. Vergeet alleen niet dat je ook een mechanisme moet hebben wat ervoor zorgt dat de pagina opnieuw opgehaald wordt. Expire header van over 5 maanden betekent dat een standaard browser die pagina 5 maanden niet meer gaat ophalen.
Daarom gooi ik in de bestandsnaam een hashwaarde of filemtime mee ( vb. fullcss.20080716.php ) en haal ik dit er met een .htaccess er wel weer uit, bij de eerste wijziging van het bestand worden er nieuwe links gecreeerd zodat elke css wijziging gelijk ( / volgende dag ) doorwerkt en ik niet nog 5 maanden lang mensen met oude css heb werken.

[Cartman!]

Ik wil hem een cachetijd van een week meegeven oid. Ik laat de controller output cachen door Zend zelf. Hopelijk krijg ik die caching weer werkend dat ie mn Content-Type header weer werkend krijg... Ik ga het morgenochtend uitgebreid testen met de expire header en vooral geen F5 Hopelijk was dat t dan want ik werd er wel een beetje gek van

[Cartman!]

Het werkt

Het kwam inderdaad door de F5 refresh ipv. doorklikken. Ook bleek Zend_Cache_Frontend_Page niet helemaal lekker te werken. In de nieuwe versie in SVN is er een fix voor en kun je ook kiezen welke headers je wil cachen, dat heb ik gedaan en voila: mn files worden keurig gecacht.

De link naar de zend fix: http://framework.zend.com/issues/browse/ZF-2841 voor de volledigheid.

Bedankt voor de hulp

edit: voor de duidelijkheid... ik gebruik nu dit:

PHP:

function setExpireHeader($argIntTimeOffset)
{
    header('Expires: ' . gmdate('D, d M Y H:i:s', time() + $argIntTimeOffset) . ' GMT');
    header('Cache-Control: public');
}

[ Voor 22% gewijzigd door Cartman! op 17-07-2008 09:39 ]

[Verwijderd]

Cartman! schreef op woensdag 16 juli 2008 @ 16:16:
Ik ben bezig met een methode waarbij ik via een controller (Zend Framework) met 1 request al mn css files opvraag en strip van onnodige data (whitespaces, tabs, comments etc). Dit werkt helemaal geweldig op 1 ding na: de file wordt niet gecached door de browser.

Hoe weet je zeker dat je browser het bestand niet cached? Veel browsers sturen namelijk een 'Conditional-Get' voor content waarvan je hebt gezegd dat het gecached mag worden. Wanneer je dan braaf een 'Not Modified' stuurt, en dus geen data, zal de browser het bestand uit de cache halen.

[Cartman!]

Omdat mn controller gewoon werd aangroepen was het een gewone get request, het zat em gewoon in de expire header. Ik cache de volledige output van de controller nu met Zend_Cache_Frontend_Page dus als een browser toch calls doet dan heb ik er geen nare serverload van verder.