http caching vb.net - image expires

[Vinzzz243]

Ik heb o.a. topic [http] images uit DB, hoe te cachen? doorgenomen en verscheidene artikels over clientside caching doorgespit.

Mijn vraag: Ervan uitgaande dat browsercaching enabled is en ik voor een afbeelding een expires http header meegeef van 1 jaar in de toekomst, kloppen dan de volgende stellingen?

1. een (vervolg) request naar de afbeelding (hetzij via enteren in de adresbalk, of F5-en) doet geen request naar de server (omdat de afbeelding op deze url een jaar lang gecached wordt clientside)
2. wanneer ik de inhoud van de afbeelding (komt uit de database) wijzig, maar de URL niet, dan zou bij refresh nog altijd de huidige/oude afbeelding te zien moeten zijn. Pas op het moment dat de URL wijzigt zal ook de inhoudswijziging te zien zijn.

Als het goed is heb ik in mijn testscenario de caching headers correct meegegeven aan de afbeelding en heb ik voor de zekerheid image.aspx?id= vervangen door een url zonder querystring (de afbeelding komt uit een database).

De httpheaders:


Toch krijg ik wanneer ik wil testen of de afbeelding idd voor langere tijd clientside wordt gecached niet het gewenste resultaat. Ik wijzig niet de URL, wel de inhoud van de afbeelding, en bij iedere refresh wijzigt de inhoud mee...

Wat zie ik over het hoofd?

PS. Hoe kan ik 100% zeker weten of een request wordt gecached (zonder steeds de inhoud te moeten wijzigen zoals mijn testscenario hierboven)? In Fiddler2, firebug en httpfox zie ik wel de headers, maar een responsecode 200 en niet of het daadwerkelijk gecached is.

[TheNephilim]

Je kunt in Chrome heel gemakkelijk zien of een object gecached is:



Header 304 betekend dat ie checked of het bestand gewijzigd is. Je ziet het aantal getransferde bytes en hoe groot het bestand daadwerkelijk is.

[Vinzzz243]

TheNephilim schreef op donderdag 05 januari 2012 @ 13:27:
Je kunt in Chrome heel gemakkelijk zien of een object gecached is:

[afbeelding]

Header 304 betekend dat ie checked of het bestand gewijzigd is. Je ziet het aantal getransferde bytes en hoe groot het bestand daadwerkelijk is.

De 304 zou ik als ik expires header gebruik niet moeten krijgen toch? een 304 krijg je volgens mij alleen als je bij de server gaat controleren (etag of last modified) of de afbeelding gewijzigd is of niet.
Edit: in jouw voorbeeld is forum.css daadwerkelijk 34 KB, maar wordt er maar 257B overgehaald (waarschijnlijk de etag of lastmodified data) ? Dit is duidelijk te zien omdat er ook een 304 wordt gegeven, maar in mijn voorbeeld is dat volgens mij niet

[ Voor 18% gewijzigd door Vinzzz243 op 05-01-2012 13:55 ]

[TheNameless]

Kan je hier ook eens de request headers neer zetten?

edit:
De caching manier die jij wilt, werkt goed als er uberhaupt geen request gaat naar de server.
Als je dus een 200 terug krijgt, klopt het niet.

[ Voor 59% gewijzigd door TheNameless op 05-01-2012 14:22 ]

[Vinzzz243]

TheNameless schreef op donderdag 05 januari 2012 @ 14:03:
Kan je hier ook eens de request headers neer zetten?

Heb mijn startpost geedit, request headers zitten er nu bij.

TheNameless schreef op donderdag 05 januari 2012 @ 14:03:
De caching manier die jij wilt, werkt goed als er uberhaupt geen request gaat naar de server.
Als je dus een 200 terug krijgt, klopt het niet.

zou dan de link naar de specifieke afbeelding uberhaupt niet vermeld moeten worden in firebug? Lijkt me vreemd, ik dacht dat 'firebug' gewoon alle referenties in de dom liet zien. Hoe kan die anders weten dat het eventueel een nieuwe unieke URL voor de afbeelding betreft en dus _dan_ wel een nieuwe afbeelding moet requesten?

De 'manier die ik wil' is toch een vaak voorkomende manier toch? Afbeeldingen die weinig tot niet veranderen een expire date ver in de toekomst geven.

[ Voor 39% gewijzigd door Vinzzz243 op 05-01-2012 16:04 ]

[TheNameless]

Ik denk dat het probleem is dat er een Last-Modified header wordt terug gegeven.
De browser neemt dan aan dat je voor die URL altijd weet of hij nieuwer is dan de versie die hij gecached heeft staan en stuurt dus in volgende requests een If-Modified-Since mee.

Vervolgens check je daar niet op en geef je een 200 terug met weer een Last-Modified header.

Ik neem aan dat je bij Firebug in de "net" tab kijkt? Daar laat Firebug namelijk alle requests zien die de browser doet.
Je zou dan inderdaad geen request moeten zien TENZIJ je cache leeg is, het image expired is of als je op CTRL+F5 gedrukt hebt.

[Vinzzz243]

TheNameless schreef op donderdag 05 januari 2012 @ 22:53:
Ik denk dat het probleem is dat er een Last-Modified header wordt terug gegeven.
De browser neemt dan aan dat je voor die URL altijd weet of hij nieuwer is dan de versie die hij gecached heeft staan en stuurt dus in volgende requests een If-Modified-Since mee.

Vervolgens check je daar niet op en geef je een 200 terug met weer een Last-Modified header.

Ik neem aan dat je bij Firebug in de "net" tab kijkt? Daar laat Firebug namelijk alle requests zien die de browser doet.
Je zou dan inderdaad geen request moeten zien TENZIJ je cache leeg is, het image expired is of als je op CTRL+F5 gedrukt hebt.

Hmz ok. Weet je ook waarom de browser die last modified meegeeft?

Ik check er inderdaad niet op (zou dat ook niet willen), wil echt gebruik maken van die 1 jaar expires date.
Ik kijk inderdaad in de "net" tab van firebug in firefox.

Kun jij me de gouden tip geven hoe ik mijn scenario wel werkend krijg?

[ Voor 54% gewijzigd door Vinzzz243 op 06-01-2012 13:26 ]

[TheNameless]

Vinzzz243 schreef op vrijdag 06 januari 2012 @ 13:25:
[...]

Hmz ok. Weet je ook waarom de browser die last modified meegeeft?

Ik check er inderdaad niet op (zou dat ook niet willen), wil echt gebruik maken van die 1 jaar expires date.
Ik kijk inderdaad in de "net" tab van firebug in firefox.

Kun jij me de gouden tip geven hoe ik mijn scenario wel werkend krijg?

Je browser geeft niet de Last-Modified mee, die geeft een If-Modified-Since mee.
Als je er voor zorgt dat de server geen Last-Modified terug geeft, dan gaat volgens mij de browser ook geen If-Modified-Since meer meegeven in toekomstige requests.

[Vinzzz243]

TheNameless schreef op vrijdag 06 januari 2012 @ 19:32:
[...]

Je browser geeft niet de Last-Modified mee, die geeft een If-Modified-Since mee.
Als je er voor zorgt dat de server geen Last-Modified terug geeft, dan gaat volgens mij de browser ook geen If-Modified-Since meer meegeven in toekomstige requests.

Klopt, maar dit scenario heb ik ook al gehad. Heb het nu aangepast, en krijg dan de volgende informatie te zien (overigens nog altijd een 200 response code).


Edit:

Problem solved!
Ik moest rekening houden met de 3 'refresh'-manieren in Firefox:

1. druk op ENTER in adresbalk of klik op linkje --> Caching expires werkt zoals behoren.
2. druk op reload knop --> Browser geeft max-age=0 mee (of if modified since). Om caching werkbaar te maken, moet op de server dit afgehandeld worden door een 304 terug te geven.
3. Hard refresh (ctrl+F5) --> Browser geeft een pragma:no-cache en cache-control: no-cache mee. Plaatje wordt dus altijd opnieuw opgehaald.

Het liefste wil ik voor images die nooit veranderen, geen request naar de server (middels max-age of if modified). Dat los ik op door expires (of max-age) te gebruiken. Op momenten dat toch iemand op reload button of ctrl+F5 drukt, moet ik de server toch inrichten om een 304 terug te geven.

[ Voor 42% gewijzigd door Vinzzz243 op 09-01-2012 12:09 ]