webForumDet fria alternativet

Förhindra att webbläsare använder cachad CSS efter re-deployment

.NET

6 svar · 1 278 visningar · startad av dAEk

Medlem sedan feb. 20041 816 inlägg
Frågan#1

Då och då behöver man ändra sin markup och CSS och eftersom man vill cacha sin CSS behöver man någon form av versionshantering så att ens besökare alltid använder den senaste versionen, annars är risken stor att den cachade versionen används och saker och ting överlappar, visas i fel storlek, färg osv.

Supervanligt problem men hur löser man det i asp.net?

Jag vill helst undvika att gå in och ändra sökvägarna eller lägga in en wrapper (servertag). Istället tänker jag mig att det borde funka med en HttpHandler som använder en appSetting (t.ex. "app.buildVersion") vars värde inkrementeras vid varje publicering/deployment/app_onstart. Handlern ansvarar sedan för att modifiera outputten och lägga till värdet i ens sökvägar. Då kan man sätta sina cache-headers långt fram i tiden och trots det kommer webbläsarna "luras" till att använda den senaste versionen.

Men... eftersom jag inte har koll på alla koncept inom asp.net har jag säkert missat något.

Hur gör ni? Finns det andra, bättre metoder?

Medlem sedan jan. 2001373 inlägg
#2

Tänkte snabbt bara... Kanske är knasigt men.

Kan du göra en kontroll som lägger in din css med build nr. ?

kontrollen laddar bara:

 

<link rel="stylesheet" type="text/css" href="controls.css?rev=<ditt app.buildVersion>"/>
Medlem sedan dec. 19996 522 inlägg
#3

Kör du MVC eller Webforms, använder du cont. integration?

Medlem sedan feb. 20041 816 inlägg
#4

Trodde faktiskt att det skulle droppa in fler svar än bara två. Ställde jag frågan fel eller nåt?

@Martin: Jo, det där funkar så klart men det är så jag egentligen inte vill göra. Det måste finnas bättre sätt!

Vi får se, jag har funderat på att introducera (N)Ant för de andra men jag är lite halvskeptisk till hur det kommer bemötas. Jag vet inte, det kan vara svårt att se behovet och rätt krångligt i början när man inte är van att jobba med det men jag saknar det, även fast jag inte är nå vidare på byggskript.

Det går att göra samma sak (och mer därtill) med NAnt, det är därför jag tar upp det. Tänkte försöka samla på mig ett par bra argument först och sen får vi se hur det blir med den här frågan men jag är fortfarande intresserad av hur ni andra gör.

Trevlig kväll :bire

/r:
@erka: Vi kör med WebForms.

Medlem sedan aug. 20011 346 inlägg
#5

en gång för länge sen gjorde jag nån funktion som la till en slumpad siffra, eller tiden i millisekunder, i filnamnet. därav skapades alltid en ny fil i cachen, men det var inte css-filen, kanske är annorlunda... kan det vara nåt?

Medlem sedan dec. 20003 563 inlägg
#6

Är väl ungefär det som sagts: http://www.webforum.nu/showthread.php?t=145456

Annars rent allmänt.
Klienten skicka en HTTP header "If_Modified_Since" inkl datum som klienten cachat filen, som webbservern jämför med den fil som efterfrågas i GET. Är filen på servern modifierad senare än det värde som klienten anger, skickas en ny fil till klienten och anger HTTP kod 200. Om filen på servern inte är modifierad efter klienten värde, skickas 304 Not modified. Och som din problemställning säger: ibland skickar servern 304 fast filen faktiskt är ändrad.

1. Så antingen kan du appenda fil.css?<uniqe-value> till filen för gå runt serverns cachning av fil.css och alltid returnera 200 (den fräscha filen).
2. Appenda fil.css?<version-value> till filen för gå runt serverns cachning endast vid versionsbyte.
3. Du kan eventuell konfigurera din server att inte cacha den filen/filtypen alls. ( Apache i stil med ExpiresByType text/css “access plus 1 second” )
4. Låt din css-fil vara en server exekverad fil (.php,asp,...) och sätt passande no-cache header vilken gör att filen aldrig cachas.

Kan nämnas att alla utom 2:an förmodligen slöar ner din webbtjänst i någon grad.

Medlem sedan feb. 20041 816 inlägg
#7

cyprys skrev:

[...]

(Kapat för att det inte ska bli så köttigt)

Jag vet inte om jag vill in och ändra i IIS:ns cacheinställningar för jag kan inte säga att jag har koll på vilka ovälkomna effekter det kan bli. Om jag ändå skulle vilja gå in och pilla i IIS:n, kan man ändra cache-inställningarna per filtyp och går det att göra det globalt eller gör man det per sajt? Det vore hur som helst trevligt om man kom undan manuellt jobb.

Angående förslagen: Mja, mjo, nja..

1 och 2)
Jo, men det funkar inte om man använder @import i sina CSS-filer. De filerna kommer inte kunna använda versionsnumret. Hur blir det med embeddade CSS-filer (WebResources)? Inte för att vi kör med sådana vad jag vet, men ändå. Det var därför jag kom in på att använda en handler som parsar HTML-koden innan den skickas iväg till webbläsarna. Då behöver man iofs konfa servrarna också vilket egentligen inte är nåt problem men som sagt, det vore sjyst om man slapp manuella ingrepp.

  1. Det är inte ett alternativ.

  2. Det är inte ett alternativ.

Att det finns så många olika sätt att infoga CSS/JS förvirrar mig. Det i kombination med att man ibland vill in och pilla i CSS:n på servern utan att behöva deploya om hela appen. Visst är det lite fy! att göra så men ibland är man lat. Risken att man glömmer checka in ändringen i SVN - ja, den finns där.

Samtidigt som jag funderar på den här frågan är jag ute efter att minska HTTP-anropen genom att slå ihop filerna till en. Man skulle kunna utgå ifrån att alla filer i en mapp kan slås ihop och få ett versionsnummer eller MD5-summa. Fast då får man inte generera CSS med en Handler...

Nåja, det kanske är bäst att utgå ifrån de projekt man själv är inblandad i. Visst skulle det vara trevligt att fixa en lösning som täcker en massa olika scenarion men man kan inte få allt. Fast det vore sjyst... ;)

360 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
216 ms — deklarationer (db)
0 ms — hämta statistik (cache)
139 ms — hämta tråd, inlägg och bilagor (db)
219 ms — ändringar (db)