nut van css/js bestanden steeds te herladen ?

[ieperlingetje]

Op verscheidene grote website's (waaronder tweakers) merk ik dat er altijd een willekeurig getal aan css/ js bestanden wordt geplakt. (bijv. http://tweakimg.net/x/min/framework.css?1250066709) maar wat is het nut hiervan? Je kunt geen caching doen, en alle zooi wordt steeds opnieuw gedownload. Niet dat ik dat erg vind. (tweakers laad altijd snel bij mij! Perfect! ) maar waarom hieraan bandbreedte verspillen als het toch hetzelfde bestand is dat je gebruikt?

[crisp]

Die GET-var wijzigt alleen als het bestand ook is gewijzigd, het is namelijk de timestamp van de laatste wijziging van het bestand. Hij wordt dus wel degelijk clientside gecached

[Verwijderd]

Nja zoals crisp hier al aangeeft een truckje om toch al je bezoekers zover te krijgen het nieuwste te zien, in geval dat die timestamp (tijd aanduiding in seconde bijvoorbeeld) veranderd is.

[ieperlingetje]

Ik had niet gemerkt dat het timestamps waren ik heb op veel website's dit trucje gezien, waardoor ik dacht dat de getallen telkens veranderden als ik de pagina bekeek. Bedankt voor de toelichting.

[ Voor 6% gewijzigd door ieperlingetje op 02-09-2009 19:48 ]

[Cartman!]

Zulke files krijgen vaak een lifetime cache mee, dus status "nooit meer ophalen" als ie eenmaal binnen is. Als je dan een wijziging hebt moet je die dus pushen want anders gaan je gebruikers nooit de wijziging zien.

[Manuel]

crisp schreef op woensdag 02 september 2009 @ 19:23:
Die GET-var wijzigt alleen als het bestand ook is gewijzigd, het is namelijk de timestamp van de laatste wijziging van het bestand. Hij wordt dus wel degelijk clientside gecached

Dan ben ik wel benieuwd naar de werking ervan, gaat het ook gewoon per database of eerder gewoon via een file attribuut (laatst aangepast bijvoorbeeld). Zie het namelijk steeds vaker terug komen maar niemand gaat er echt op in

[matthijsln]

Manuel schreef op donderdag 03 september 2009 @ 10:33:
[...]
Dan ben ik wel benieuwd naar de werking ervan, gaat het ook gewoon per database of eerder gewoon via een file attribuut (laatst aangepast bijvoorbeeld). Zie het namelijk steeds vaker terug komen maar niemand gaat er echt op in

Deze methode vermijdt conditional GET requests (304 Not Modified). Zoals in de response headers is te zien wordt aan de browser duidelijk gemaakt dat de URL geldig is voor een aantal maanden met Cache-control en Expires headers. Als voor die expire tijd toch het bestand wordt aanpast, moet je dus een andere URL gebruiken. Het toevoegen van een URL parameter met de timestamp van laatste wijziging is daar geschikt voor. Dat gebeurt dus in de HTML code die het CSS bestand refereert, met bv php.

Dit heeft alleen zin bij sites met veel traffic, 304 Not Modified responses zijn bij niet-high traffic sites niet zo belastend en kosten ook niet erg veel dataverkeer.

[Manuel]

Heel erg bedankt voor het stukje informatie, het is dus in feite gewoon handmatige cache-control als ik het allemaal zo lees. Ik ga eens verder zoeken op dit soort informatie. Nog maals bedankt! :-)

[Niox]

crisp schreef op woensdag 02 september 2009 @ 19:23:
Die GET-var wijzigt alleen als het bestand ook is gewijzigd, het is namelijk de timestamp van de laatste wijziging van het bestand. Hij wordt dus wel degelijk clientside gecached

Als ik dit artikel mag geloven, klopt dat toch niet helemaal (paragraaf 'Mistakes abound').

O.a. Opera en Safari zouden urls met een vraagteken erin nooit cachen, En dus zou je, met hulp van een rewriterule, beter bestandsnamen als print.v2.css (ipv print.css?123) kunnen gebruiken:

At this point, you might ask why we don’t just add a query string to the end of the resource – /css/main.css?v=4. According the letter of the HTTP caching specification, user agents should never cache URLs with query strings. While Internet Explorer and Firefox ignore this, Opera and Safari don’t – to make sure all user agents can cache your resources, we need to keep query strings out of their URLs.

[crisp]

Niox schreef op vrijdag 04 september 2009 @ 00:53:
[...]


Als ik dit artikel mag geloven, klopt dat toch niet helemaal (paragraaf 'Mistakes abound').

O.a. Opera en Safari zouden urls met een vraagteken erin nooit cachen, En dus zou je, met hulp van een rewriterule, beter bestandsnamen als print.v2.css (ipv print.css?123) kunnen gebruiken:


[...]

Voor zover ik weet klopt dat gewoonweg niet. Ik zie ook geen pointer in dat artikel naar een relevante specificatie die zegt dat URL's met querystrings niet gecached zouden mogen worden. Naar mijn weten zijn er ook geen issues met Safari en/of Opera op dat vlak.

De enige issues die zouden kunnen voorkomen worden veroorzaakt door verouderde proxies die resources onafhankelijk van querystrings cachen, maar dat is wel non-spec-compliant en komt volgens mij niet zo veel meer voor.

[ Voor 12% gewijzigd door crisp op 04-09-2009 01:05 ]

[Niox]

crisp schreef op vrijdag 04 september 2009 @ 01:02:
[...]

Voor zover ik weet klopt dat gewoonweg niet. Ik zie ook geen pointer in dat artikel naar een relevante specificatie die zegt dat URL's met querystrings niet gecached zouden mogen worden. Naar mijn weten zijn er ook geen issues met Safari en/of Opera op dat vlak.

Mja ik ben wel eens aan het lezen geslagen hierover maar helemaal duidelijk of het nou klopt of niet is het mij niet geworden.

Aan de ene kant verwacht je van het technisch brein achter een site van het formaat Flickr niet dat hij zomaar onzin uitkraamt, en de andere kan ook zo iemand er een keer faliekant naast zitten natuurlijk. Voorlopig pas ik het maar gewoon toe. Kwaad kan het niet, en het voorkomt onbewust niet-cachen mocht zijn verhaal toch correct zijn.

[Wolfboy]

crisp schreef op vrijdag 04 september 2009 @ 01:02:
[...]

Voor zover ik weet klopt dat gewoonweg niet. Ik zie ook geen pointer in dat artikel naar een relevante specificatie die zegt dat URL's met querystrings niet gecached zouden mogen worden. Naar mijn weten zijn er ook geen issues met Safari en/of Opera op dat vlak.

De enige issues die zouden kunnen voorkomen worden veroorzaakt door verouderde proxies die resources onafhankelijk van querystrings cachen, maar dat is wel non-spec-compliant en komt volgens mij niet zo veel meer voor.

Correct, alle moderne browsers handelen dit prima af.

edit:
Disclaimer: wel met de correcte headers, anders nog steeds niet

Maar er zijn wel een lading proxies die dit standaard niet cachen of zeer voorzichtig cachen. Ik meen mij te herinneren dat dit ook het geval is bij de standaard squid configuratie waarbij er beter naar de headers gekeken wordt of er geupdate moet worden of niet.

[ Voor 3% gewijzigd door Wolfboy op 04-09-2009 01:25 ]

[crisp]

Een simpele test met Opera 9.6x en Wireshark debunked in ieder geval de claim dat Opera geen resources met een query-string zou cachen...

Wolfboy schreef op vrijdag 04 september 2009 @ 01:23:
[...]
Correct, alle moderne browsers handelen dit prima af.

edit:
Disclaimer: wel met de correcte headers, anders nog steeds niet

Maar er zijn wel een lading proxies die dit standaard niet cachen of zeer voorzichtig cachen. Ik meen mij te herinneren dat dit ook het geval is bij de standaard squid configuratie waarbij er beter naar de headers gekeken wordt of er geupdate moet worden of niet.

squid is gewoon een totale non-conformant disaster (net als veel andere proxy-software overigens)...

[ Voor 69% gewijzigd door crisp op 04-09-2009 01:33 ]

[Wolfboy]

crisp schreef op vrijdag 04 september 2009 @ 01:31:
Een simpele test met Opera 9.6x en Wireshark debunked in ieder geval de claim dat Opera geen resources met een query-string zou cachen...

Hou je dan ook rekening met het ontbreken van de ctrl+F5 feature van Firefox/IE?

Bij Opera betekend een F5 namelijk wel het opnieuw ophalen van de CSS als er get parameters zijn en bij Firefox/IE niet.

squid is gewoon een totale non-conformant disaster (net als veel andere proxy-software overigens)...

Mwah, Squid is configureerbaar non-conformant. Die is nog wel redelijk goed te krijgen maar dan krijg je problemen met ladingen websites die daar niet vanuit gaan.

Maarja, proxies in het algemeen zijn een ramp ja.

[crisp]

Wolfboy schreef op vrijdag 04 september 2009 @ 10:39:
[...]
Hou je dan ook rekening met het ontbreken van de ctrl+F5 feature van Firefox/IE?

Bij Opera betekend een F5 namelijk wel het opnieuw ophalen van de CSS als er get parameters zijn en bij Firefox/IE niet.

Firefox en IE doen ook conditional requests voor alle resources bij een 'gewone' F5, net als Opera. Je ziet dan ook 304 responses.

[Wolfboy]

Dat moet dan veranderd zijn.
Het was namelijk bij een aantal browsers zo dat als je Expires in de toekomst zette, Cache-Control alleen op public en geen etag, dat de browser dan netjes de instructies van de server volgde en die bestanden niet meer ging ophalen.

[crisp]

Wolfboy schreef op vrijdag 04 september 2009 @ 13:34:
Dat moet dan veranderd zijn.
Het was namelijk bij een aantal browsers zo dat als je Expires in de toekomst zette, Cache-Control alleen op public en geen etag, dat de browser dan netjes de instructies van de server volgde en die bestanden niet meer ging ophalen.

Bij gewoon navigeren doet een browser dat ook niet, maar F5 doet conditional requests en ctrl+F5 unconditional (als in: stuurt geen If-Modified-Since, If-Non-Match mee)

[_Thanatos_]

crisp schreef op vrijdag 04 september 2009 @ 13:48:
Bij gewoon navigeren doet een browser dat ook niet, maar F5 doet conditional requests en ctrl+F5 unconditional (als in: stuurt geen If-Modified-Since, If-Non-Match mee)

Bijna goed, want in Opera betekent Ctrl+F5 zoiets als "alle tabs refreshen met normale F5". En bij mijn weten is een F5 refresh een onconditionele refresh. In de adresbalk op enter drukken doet een conditionele refresh.

In andere browsers klopt het redelijk wat je zegt