Duplicate cache headers in spring boot 1.5.1

[apixandru]

There's this bug in IE that the fonts from fonts awesome don't work very well with https. It has some problems with caching or something. (see FortAwesome/Font-Awesome#6454 )

To get around this, we set up a filter registration bean.

@Bean
public FilterRegistrationBean fixIeHttpsFontCache() {
	FilterRegistrationBean registration = new FilterRegistrationBean();
	registration.setFilter(new InternetExplorerHttpsFontFilter);
	registration.setDispatcherTypes(EnumSet.allOf(DispatcherType.class));
        registration.setUrlPatterns(/*urls for fonts */);
	return registration;
}

The Internet Explorer Https Font filter would just set the http request headers to

Expires -1
Cache-control public
Pragma cache

This worked fine until 1.4.4, but on 1.5.1 it no longer works. I'm guessing that the way to set headers has changed lately or that the filters should be registered differently?

[wilkinsona]

I'm guessing that the way to set headers has changed lately or that the filters should be registered differently?

Neither of those things has changed as far as I know.

Have you dug into why it no longer works? I'm guessing that the headers aren't getting set as you intend. It should be possible to verify that without involving IE, for example by using curl. Can you provide a small sample that illustrates the problem?

[apixandru]

Just by looking at the request, it appears that the default content type has changed from spring 1.4.4 for eot type fonts from application/octet-stream to application/vnd.ms-fontobject

[wilkinsona]

As far as I can tell, there's no content type in 1.4.4:

curl --head -i http://localhost:8080/fontawesome-webfont.eot
HTTP/1.1 200
Last-Modified: Fri, 03 Feb 2017 13:54:12 GMT
Accept-Ranges: bytes
Content-Length: 165742
Date: Fri, 03 Feb 2017 13:54:18 GMT

With 1.5 it's application/vnd.ms-fontobject as you have observed:

curl --head -i http://localhost:8080/fontawesome-webfont.eot
HTTP/1.1 200
Last-Modified: Fri, 03 Feb 2017 13:55:17 GMT
Accept-Ranges: bytes
Content-Type: application/vnd.ms-fontobject
Content-Length: 165742
Date: Fri, 03 Feb 2017 13:57:05 GMT

That change is a result of this commit. We added some more mappings when upgrading to a new version of Undertow as we make sure that the mappings are consistent across all three supported embedded containers (Tomcat, Undertow, and Jetty).

If that change is what's causing your problem (you haven't confirmed that yet) then I don't think there's anything we can do about it and you'll have to find an alternative workaround.

[apixandru]

It looks like this is loosely linked to #8176

I took a quick look on the deployment server and it looks like my cache headers are in fact being 'overridden'.

Spring boot 1.5.1

Response            HTTP/1.1 200 OK
Date      Fri, 03 Feb 2017 15:02:48 GMT
[…]
Cache-Control   public
Cache-Control   no-cache, no-store, max-age=0, must-revalidate
Pragma cache
Pragma no-cache
Accept-Ranges  bytes
Expires 0
Last-Modified    Fri, 03 Feb 2017 15:00:47 GMT
[…]

Spring boot 1.4.4

Response            HTTP/1.1 200 OK
Date      Fri, 03 Feb 2017 15:18:53 GMT
[…]
Cache-Control   public
Pragma cache
Accept-Ranges  bytes
Expires -1
Last-Modified    Fri, 03 Feb 2017 15:15:26 GMT
[…]

It looks like before it wasn't adding the Pragma / Cache-Control / Expires headers if they were already defined but now they are added regardless.

Locally this it works fine for me but I don't have a https connection locally and this bug is only available with https.

Also, I forgot to mention that this is when deploying to weblogic, I'm not sure if it's relevant or not.

[wilkinsona]

This issue's all over the place at the moment. So it looks like you're now saying that the Content-Type header has nothing to do with the problem?

You haven't said how you've configured the static resource handling and where you've configured the caching. As you can see in the curl output I shared above you won't get any caching headers by default so you must have configured something that's setting them in addition to your custom filter.

Can you please share some code that reproduces the problem?