[ALG] hoe controleren of browser cache gebruikt of niet

[marty]

Ik ben wat aan het experimenteren met caching van CSS files en ben nu aan het zoeken hoe ik kan controleren of de browser idd de gecachte file gebruikt of niet. Ik kom onwijs veel topics tegen over problemen met cache en hoe dat op te lossen, maar daar heb ik dus niets aan. Het gaat mij alleen om de vraag: is de file uit de cache getrokken ja of nee?
Het probleem is dat als ik een wijziging maak ik niet wil dat ie uit z'n cache getrokken wordt, dus als ik de wijziging zie is dat goed. En als ik geen wijziging maak dan moet ie 'm wel uit z'n cache trekken, maar dan heb ik dus niets meer om te controleren. Ook de gecachte file op m'n HD aanpassen helpt niet, want die komt dan niet meer overeen met de file op de server, dus zou hij 'm niet moeten gebruiken.

Voor degene die de achtergrond willen weten, ik wil graag kijken hoe de browser met de caching van geimporteerde css files omgaat (via de @import regel), met dynamische css files gegenereer door PHP en met een .php extentie (al dan niet met extra headers die het cachen manipuleren) en dynamische CSS files met een .css extentie (waarbij de server verteld is dat die ook geparsed moeten worden door PHP).

Maargoed, heeft iemand een suggestie hoe ik dit kan controleren? Heb ook nog naar plugins van Firefox gezocht (wat IE doet maakt me eigenlijk niet zoveel uit), maar helaas.

[Sendy]

Zet die css files ergens op een server. Installeer een packet sniffer en kijk of het stylesheet over de lijn gaat. Note dat er vaak wel HEAD requests gedaan worden; dit is om te controlleren of er een nieuwe stylesheet versie is.

[ Voor 34% gewijzigd door Sendy op 05-07-2006 14:18 ]

[Upsal]

Wil je dit alleen voor jezelf controleren? Zoja; dan zou je bijv. een SQL query kunnen plaatsen in je css file, als er een request is richting de css, dan wordt de query uitgevoerd, anders niet.

[crisp]

Extentie zou niet uit mogen maken als je gewoon de juiste caching-headers stuurt. Mijn vraag is echter waarom je dynamisch je CSS zou willen samenstellen, vaak is dat namelijk niet nodig. Houd in ieder geval je dynamische stylesheets zo klein mogelijk - enkel aanvullend op een statische default stylesheet

[Verwijderd]

crisp schreef op woensdag 05 juli 2006 @ 14:34:
Extentie zou niet uit mogen maken als je gewoon de juiste caching-headers stuurt. Mijn vraag is echter waarom je dynamisch je CSS zou willen samenstellen, vaak is dat namelijk niet nodig. Houd in ieder geval je dynamische stylesheets zo klein mogelijk - enkel aanvullend op een statische default stylesheet

Omdat je achterliggende systeem modulair kan zijn opgebouwd, en elke module daarbij zijn eigen css heeft. Je wilt echter ook voorkomen dat je voor al je 20 modules een @import moet uitvoeren die pas niet meer van belang is als de bestanden de eerste keer zijn gecached bij de client.

In dat geval combineer je dus alle 20 modules in een enkele bestand en duw je die met een streamwriter naar de gebruiker. Dan hou je tevens een connectie beschikbaar voor ander werk.

Puur een voorbeeldsituatie

[marty]

Wil je dit alleen voor jezelf controleren? Zoja; dan zou je bijv. een SQL query kunnen plaatsen in je css file, als er een request is richting de css, dan wordt de query uitgevoerd, anders niet.

goeie! had ik zelf nog niet aan gedacht
alleen gaat die niet op voor de @import die ik ook wil controleren.
die kan ik natuurlijk gewoon naar een dynamische laten verwijzen. bedankt! dan heb ik de oplossing

Zet die css files ergens op een server. Installeer een packet sniffer en kijk of het stylesheet over de lijn gaat.

hmm..daar heb ik niet zoveel ervaring mee. weet je toevallig ergens een (gratis) packetsniffer die daarvoor geschikt is?

Extentie zou niet uit mogen maken als je gewoon de juiste caching-headers stuurt.

Dat weet ik, maar ik wil dus controleren of het wel het gewenste effect heeft De theorie die hier en daar op internet te lezen is, is niet altijd de praktijk.

Mijn vraag is echter waarom je dynamisch je CSS zou willen samenstellen, vaak is dat namelijk niet nodig.

Ten eerste omdat er sprake is van verschillende templates die alleen in kleur en wat images af gaan wijken. Die template is afhankelijk van hoe je inglogt. Ik kan ook wel 15 verschillende stylesheets maken voor 15 templates, maar als ik dan een wijziging aan wil brengen moet ik 15 verschillende files wijzigen. 1 dynamische leek me dus wat makkelijker qua onderhoud. Na het inloggen zal er niets meer wijzigen, dus de stylesheet mag verder gewoon gecached worden. En da's precies waar ik nu mee bezig ben
Ten tweede omdat ik de gebruiker in de toekomst misschien ook (heeeeel beperkt) zelf wat instellingen wil laten kunnen wijzigen.

[ Voor 4% gewijzigd door marty op 05-07-2006 17:02 ]

[crisp]

marty schreef op woensdag 05 juli 2006 @ 17:00:
[...]
Ten eerste omdat er sprake is van verschillende templates die alleen in kleur en wat images af gaan wijken. Die template is afhankelijk van hoe je inglogt. Ik kan ook wel 15 verschillende stylesheets maken voor 15 templates, maar als ik dan een wijziging aan wil brengen moet ik 15 verschillende files wijzigen. 1 dynamische leek me dus wat makkelijker qua onderhoud. Na het inloggen zal er niets meer wijzigen, dus de stylesheet mag verder gewoon gecached worden. En da's precies waar ik nu mee bezig ben

Da's ook precies wat we hier op GoT doen; we bieden 7 verschillende styles aan - dat zijn echter maar heel kleine stylesheets, alle styles die gedeeld worden staan in een default.css

Ten tweede omdat ik de gebruiker in de toekomst misschien ook (heeeeel beperkt) zelf wat instellingen wil laten kunnen wijzigen.

Dat is een goede reden, maar dan nog zou ik een default stylesheet hanteren en een dynamische daarbovenop.

Wat Gordijnstok zegt is wel een goede reden om mbv serverside scripting een stylesheet op te sturen: namelijk het samenvoegen van vele kleintjes om requests uit te sparen, maar dat lijkt me hier nauwelijk het geval

[Sendy]

marty schreef op woensdag 05 juli 2006 @ 17:00:
[...]
hmm..daar heb ik niet zoveel ervaring mee. weet je toevallig ergens een (gratis) packetsniffer die daarvoor geschikt is?
[...]

Sniffen lijkt me veel handiger dan een SQL query; juist omdat er soms HEAD request gestuurd kunnen worden. Een free-as-in-freedom sniffer is ethereal (maar die had je ook wel zelf kunnen zoeken). Je capturet eerst je verkeer en daarna bekijk je de stream met de optie om hele tcp sessies te zien (of misschien zijn er tegenwoordig beter opties, ik zie dat er nu versie 0.99 is).

[marty]

crisp schreef op woensdag 05 juli 2006 @ 17:50:
Dat is een goede reden, maar dan nog zou ik een default stylesheet hanteren en een dynamische daarbovenop.

waarom? want

crisp schreef op woensdag 05 juli 2006 @ 14:34:
Extentie zou niet uit mogen maken als je gewoon de juiste caching-headers stuurt.

Ik bouw m'n stylesheets inderdaad zo op dat al het standaard werk in 1 stylesheet komt te staan en dat daarboven op andere stylesheet geladen worden die voor specifieke delen gelden.
Maar wat is er op tegen om die ene standaard stylesheet bepaalde dynamische elementen te geven? Want die zijn alleen dynamisch in de zin van hoe je inlogt. Daarna zal het niet meer veranderen en hij mag/zal dus gewoon gecached worden.
Ik zie het nadeel dus niet zo