Expire Header werkt niet bij transip.nl

[lowfi]

Ik heb een premium webhosting pakketje bij transip.nl. Daar dacht ik simpel in de htaccess de header expire aan te passen met bv:

code:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "access plus 1 year"
</FilesMatch>

Als ik dit doet krijg ik een error 500 voor mijn neus. Iets zegt me dat mod_expires niet geactiveerd is? Of ligt dit ergens anders aan?

[TheNephilim]

code:

<FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$">
    ExpiresDefault "access plus 1 month"
</FilesMatch>

Ik zou sowieso niet voor een jaar kiezen, liever korter! Probeer bovenstaande eens, de slash zou het verschil kunnen maken en hier staan de hoofdletter netjes.

[RobIII]

TheNephilim schreef op donderdag 02 mei 2013 @ 23:03:
Ik zou sowieso niet voor een jaar kiezen, liever korter!

Heulegaar nie! Een "far future" expiratiedatum is voor static resources juist aanbevolen:

Set Expires to a minimum of one month, and preferably up to one year, in the future.

Er zijn zelfs bronnen die aangeven nog liever 10 jaar of "never expire" te gebruiken.

@lowfi: Al voor de gein eens in de documentatie gekeken? Daar is 'ie voor en staat 't gewoon letterlijk in namelijk

[ Voor 53% gewijzigd door RobIII op 02-05-2013 23:17 ]

[R4gnax]

RobIII schreef op donderdag 02 mei 2013 @ 23:06:
Er zijn zelfs bronnen die aangeven nog liever 10 jaar of "never expire" te gebruiken.

10 jaar? Weet je meteen dat ze de ballen verstand hebben van waar ze mee bezig zijn:

RFC2616 - HTTP/1.1:
To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.

[RobIII]

R4gnax schreef op vrijdag 03 mei 2013 @ 01:50:
10 jaar? Weet je meteen dat ze de ballen verstand hebben van waar ze mee bezig zijn:

Die RFC is leuk maar in de tijd dat Netscape nog met IE ruzie had om 't grootste marktaandeel stuurden websites (waaronder Google, ik heb geen bronnen maar 't indertijd wel zelf waargenomen) al expiry dates van 2038 en er is, AFAIK, geen enkele browser die daar moeite mee had noch heeft*. Daarbij zeg ik er duidelijk bij "never expires" en ben ik die 10 jaar (hoewel in een example en geen recommendation) toch echt tegen gekomen bij niet de minste. Theorie (RFC) en praktijk (En zelfs de RFC zegt SHOULD NOT i.p.v. MUST NOT).

Enfin, boeie wat je precies gebruikt enzo; het punt was duidelijk: waarom adviseren die datum korterbij te halen?

* Ik meen me overigens wel te herinneren dat een aantal browser implementaties (waaronder waarschijnlijk recente versies ook wel) alles meer dan een jaar wel beschouw(d)en als precies één jaar (dus "afkappen" zeg maar).

[ Voor 22% gewijzigd door RobIII op 03-05-2013 02:16 ]

[R4gnax]

RobIII schreef op vrijdag 03 mei 2013 @ 02:09:
[...]
geen enkele browser die daar moeite mee had noch heeft

Het probleem zit hem eerder in caching proxies dan in browsers; je hebt er maar één nodig die een heel stricte lezing van de RFC gebruikt en je gaat nat.

[crisp]

De eerste proxybouwer die RFC's leest en correct implementeert moet ik nog tegenkomen

Maar 10 jaar lijkt me zelf ook overdreven. Wij houden het zelf ook op een jaar. Caches zijn over het algemeen ook gelimiteerd, dus de kans dat een resource daadwerkelijk 10 jaar lang in een cache kan verblijven is behoorlijk klein

[Barryvdh]

Anyways, ik denk niet dat dat te maken heeft met zijn probleem.

Je kan de header alleen sturen, als de module aanstaat.

code:

<IfModule mod_expires.c>
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "access plus 1 year"
</FilesMatch>
</IfModule>

Zie voor meer voorbeelden (en best practices ook: https://github.com/h5bp/s...ter/apache/.htaccess#L433)
Daar staat ook een andere manier van header expires, die je anders zou kunnen proberen.

[ Voor 9% gewijzigd door Barryvdh op 03-05-2013 09:55 ]

[TheNephilim]

RobIII schreef op donderdag 02 mei 2013 @ 23:06:
[...]

Heulegaar nie! Een "far future" expiratiedatum is voor static resources juist aanbevolen:

[...]

Er zijn zelfs bronnen die aangeven nog liever 10 jaar of "never expire" te gebruiken.

@lowfi: Al voor de gein eens in de documentatie gekeken? Daar is 'ie voor en staat 't gewoon letterlijk in namelijk

Ik wist niet dat er officieel een aanbeveling was dat je beter juist hele lange expires kunt gebruiken. Zelf wil ik nog wel eens liever af en toe een refresh forcen al kan ik me voorstellen dat je bij websites met veel bezoekers het liefst zo min mogelijk je static shizzle refreshed.

Weer wat geleerd! ^^

[HuHu]

TheNephilim schreef op vrijdag 03 mei 2013 @ 10:09:
[...]




Ik wist niet dat er officieel een aanbeveling was dat je beter juist hele lange expires kunt gebruiken. Zelf wil ik nog wel eens liever af en toe een refresh forcen al kan ik me voorstellen dat je bij websites met veel bezoekers het liefst zo min mogelijk je static shizzle refreshed.

Weer wat geleerd! ^^

Als je statische content wilt "refreshen", dan geef je het een andere URL.

[TheNephilim]

En vervolgens blijft de oude content bij de client nog een jaar in cache. Vandaar dat 'temp browser files' weggooien zoveel ruimte oplevert

[Barryvdh]

TheNephilim schreef op vrijdag 03 mei 2013 @ 11:39:
En vervolgens blijft de oude content bij de client nog een jaar in cache. Vandaar dat 'temp browser files' weggooien zoveel ruimte oplevert

Je kan toch gewoon instellen hoeveel ruimte die mag gebruiken? En je browser zal waarschijnlijk gewoon als eerste de items verwijderen die het langst niet gebruikt zijn, dus dat is toch geen probleem?
Gewoon lekker lange cache gebruiken en je assets renamen als je ze veranderd.

[RobIII]

R4gnax schreef op vrijdag 03 mei 2013 @ 09:05:
Het probleem zit hem eerder in caching proxies dan in browsers; je hebt er maar één nodig die een heel stricte lezing van de RFC gebruikt en je gaat nat.

Dan zijn ze niet strikt genoeg volgens de RFC's:

quote: http://tools.ietf.org/html/rfc760

In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.

quote: http://tools.ietf.org/html/rfc1122

"Be liberal in what you accept, and conservative in what you send"

Maar nu wordt 'ie wel heel flauw Zoals ik al zei: Theorie (RFC) != praktijk

Barryvdh schreef op vrijdag 03 mei 2013 @ 11:42:
[...]

Je kan toch gewoon instellen hoeveel ruimte die mag gebruiken?

Bij IE en FX wel, Chrome niet AFAIK (en Opera weet ik niet).

[ Voor 15% gewijzigd door RobIII op 03-05-2013 11:44 ]