Multiple caching headers

[Thomas Einwaller]

I added wro4j to my Spring MVC project a couple of weeks ago and I am very happy with it so far. The only problem I have is that aggressive caching leads to JS and CSS files not reloaded by the browser when they are updates. 

I researched the web about caching and found this document by google:

https://developers.google.com/speed/docs/best-practices/caching

which seems to give some good tips. One statement caught my attention:

It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag. 

The response headers generated for wro4j for my JS resources look like:

Cache-Control	public, max-age=315360000
Content-Encoding	gzip
Content-Length	20746
Content-Type	text/javascript;charset=UTF-8
Date	Tue, 30 Jul 2013 08:07:47 GMT
Etag	"2135a7433afba4445c1e4c61372a8206cbc5b35a"
Expires	Wed, 30 Jul 2014 07:59:04 GMT
Last-Modified	Tue, 30 Jul 2013 07:59:04 GMT
Server	Apache-Coyote/1.1
Vary	Accept-Encoding

Clearly the headers are redundant - was this implemented intentionally or should this be changed?

[Alex Objelean]

Hi Thomas,

thanks for the hint. Indeed, though redundant headers do no harm, they can be removed and I'll open issue for that.

Until then, you can control the headers, by extending the WroFilter and override the "newResponseHeadersConfigurer" method. That method should return the customized ResponseHeadersConfigurer. You can take a look on default implementation to understand how to customize it.

Thanks,

Alex.

[mateusz...@gmail.com]

You are right but redundancy is a workaround. I personally observed a problem with a broken ySlow addon from Yahoo, it reports when there is cache head (HTTP 1.1) and there is no expires header that content is not cached.

[Alex Objelean]

I have created the issue: https://code.google.com/p/wro4j/issues/detail?id=768&start=100

What are the suggested actions?

- Should the default implementation of the ResponseHeadersConfigurer not set expires and cache-control headers? 

- Should it use Etag header only?

- Should it remain unchanged?

Thanks,

Alex

On Tuesday, 30 July 2013 12:16:42 UTC+3, Thomas Einwaller wrote:

[Thomas Einwaller]

Based on what Julien posted and the information here http://blog.marek.sapota.org/article/2012/08/17/web-browsers-and-cache-revalidation.html I would not change the headers now.

But I think it has to made clear that the default behaviour leads to aggressive caching of the resources and that they are not refreshed if anything changes in their content.

[Julien Wajsberg]

On 30 July 2013 15:10, Alex Objelean <alex.o...@gmail.com> wrote:

I have created the issue: https://code.google.com/p/wro4j/issues/detail?id=768&start=100

What are the suggested actions?

- Should the default implementation of the ResponseHeadersConfigurer not set expires and cache-control headers? 

- Should it use Etag header only?

- Should it remain unchanged?

Best practices usually recommend to use only the Last-Modified header, and not ETag. But this is mainly because ETag are often poorly implemented whereas Last-Modified is easier to do.

If our ETag is well implemented, it's probably better to use it instead.

About Expires and Cache-Control I don't think it's a problem to give both (Apache does this) as long as they relate to the same value.

[Thomas Einwaller]

So to make sure that the resources are refreshed when something changes in the new version of an app you would suggest sending the correct ETag and an Expires header with a value in the past?

[Alex Objelean]

I think the ETag header is not implemented very poorly :), since it uses the HashStrategy (by default SHA1HashStrategy) which guarantees to return an unique ETag value based on the generated content. What I can do, is to remove the expires by default, thus the client will always check if the server has a newer version.

Alex

--
You received this message because you are subscribed to the Google Groups "wro4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wro4j+un...@googlegroups.com.
To post to this group, send email to wr...@googlegroups.com.
Visit this group at http://groups.google.com/group/wro4j.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Julien Wajsberg]

On 30 July 2013 15:43, Alex Objelean <alex.o...@gmail.com> wrote:

I think the ETag header is not implemented very poorly :), since it uses the HashStrategy (by default SHA1HashStrategy) which guarantees to return an unique ETag value based on the generated content.

That's what I expected from such a great project ;-)

 

What I can do, is to remove the expires by default, thus the client will always check if the server has a newer version.

That's exactly what you should not do ;) If there is no Expires (or Cache-Control max-age iirc) header, the browser will use an internal heuristic.
Just put the current time or (I think, but please check in different browsers :) ) an invalid value and it should do what you want.

[Alex Objelean]

Julien,

could you update the acceptance criteria of this task? I would like to keep everything relevant here: https://code.google.com/p/wro4j/issues/detail?id=768

Thanks,

Alex

--

[Julien Wajsberg]

seems like Thomas already did it ?

[Alex Objelean]

Wasn't sure if you agree or have anything else to add.

Thanks,

Alex