Font-awesome: Remove query strings from static resources

[delight]

Resources with a "?" in the URL are not cached by some proxy caching servers. Remove the query string and encode the parameters into the URL

turn
http://iplocator.herokuapp.com/fonts/fontawesome-webfont.woff?v=4.0.3

into
http://iplocator.herokuapp.com/fonts/fontawesome-webfont-4.0.3.woff

[olegomon]

+1

It is also difficult to generate appropriate urls for application cache manifest. You cannot simply take file names for the urls to make the cache work properly. You also have to consider the current version with the query string for the urls inside the manifest. Which is not as simple as taking the filenames.

[robinwyss]

+1

[LDSign]

+1

[wnwen]

+1

[Jojo-Jojovich]

+1

[delight]

3286 is older then #3823 and #3823 is different!

Also #663 is different - just because it is about the versioning it does not mean that those issues are all the same. Please be cautious about such things.

[tagliala]

@delight are you ok now?

[tagliala]

@delight have you also read why I referred this issue from #663? Could you please read the following comment: https://github.com/FortAwesome/Font-Awesome/issues/663#issuecomment-53957309?

[delight]

I don't get it - what's your point ?

[jukkasi]

+1

Because versioning is using query strings it is impossible to get fontawesome files to get added to HTML5 application cache and ugly workaround is needed

http://stackoverflow.com/questions/24055244/webfont-font-awesome-not-working-corrently-offline

I think the version should be in the file names itself which is the recommended way to do versioning

http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

[rrajewski]

+1

[jeromegv]

+1

[ivanjuras]

+1 from me as well

[jordanrynard]

+1

[thielj]

+1

[tagliala]

Added to 5.0.0 milestone

[swbullis]

As a way to bypass this for Offline Cache you can added a custom style directly after loading the font awesome css library with them removed.

<link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css">

<style>
/*Temporary Fix for Font Awesome ApplicatonManifest offline Cache */
@font-face {
     font-family: 'FontAwesome';
     src: url('../fonts/fontawesome-webfont.eot');
     src: url('../fonts/fontawesome-webfont.eot') format('embedded-opentype'),       url('../fonts/fontawesome-webfont.woff2') format('woff2'), url('../fonts/fontawesome-webfont.woff') format('woff'), url('../fonts/fontawesome-webfont.ttf') format('truetype'), url('../fonts/fontawesome-webfont.svg') format('svg');
       font-weight: normal;
       font-style: normal;
}
</style>

[vladimirmartsul]

+1

[johnnyshields]

+1

[scotty6435]

+1!

[mehalick]

+1

[JackMorrissey]

+1

[virgofx]

+1

[virgofx]

@davegandy Any chance this could get included in 4.4.1?

[aadi27]

+1

[ghost]

+1

[CounsellingHub]

+1

[greggles]

This seems like a popular common problem and the solution has received a lot of "+1" comments.

Is this blocked on someone doing the work or is it blocked on the belief that this idea is not a good solution?

[ziahamza]

The query string makes it really hard to use font awesome in browser extension. Even a less flag to remove the query string from url would come a long way.

[andrenarchy]

+1 Currently, I have to rename the font files for inclusion in an extension.

[robert-claypool]

+1

I must enable Forward Query Strings in CloudFront only to support Font Awesome.

[mriehema]

+1

[blindpet]

I am struggling to understand why nothing is being done abut this 1 year later.

Another +1

@davegandy is there something we need to do to help move this along?

[ralphonz]

another +1. been an issue for ages

[mattbucci]

+1

[cdobbyn]

+1

[psimoneau22]

+1

[plremis]

+1

[swherdman]

+1

[drzraf]

Could someone state why these query-string reached the build-process in the first place?
(I guess it's about mobile-cache, isn't?)
Were _common_/_standard-compliant_ proxy-cache configurations considered at that time?

Query-string versioning is here to workaround buggy proxies, but shouldn't proxies assumed to behave correctly?
People who currently have correct reverse-proxy stack/configuration are the most annoyed ones.

[leecollings]

Why is this being left so long to appear in a major milestone, when it could be simply pushed out quickly? I'm just going to edit my CSS file where they're being referenced until the change comes out.

[drzraf]

• If static filenames are used like _fontawesome-webfont-4.0.3.woff_, it causes long-term issues. It's assumed to be a static file at this location. 3rd-party applications relying upon fontawesome have be aware of the version used. CDN may remove these resources later, leaving dependant component with a HTTP 404. And not all webservers may use the same rewriting/storage setup. Although workable its overkill and error-prone in most deployment cases.
• If query-string are used, it causes troubles for reverse proxies and intermediary proxies since it bypass caches in many situations and creates duplicates cache entries. It also eases cache poisoning (just GET "https://the-cdn.com/fontawesome-webfont.woff?v=<the-next-versions>" to store an old version for the next X years in reverse/intermediary proxies you crossed)
• So please remove cache-busting completely (or at least disable it by default). So that people relying on far-future Expires HTTP header have to deal with the workarounds for the problem they created themselves... and people who leave unconfigured (with proper defaults) or configure properly their Expires/Last-Modified/ETags get a simple setup that just works.

If people set their CSS/JS/fonts to Expire in 10 years they should just be given what they expect.

[mkurz]

+1

[chris-purcell]

A work around has been posted. As well, if you place the fonts on the server (or in your CDN) you don't have to use the query string at all. You only need the query string when accessing the fonts from fontawesome's servers. No fix is needed on their end. This is an end user comprehension issue.

[andrenarchy]

@chris-purcell the query string is included here so we're all using it by default. The query string confuses caches and breaks browser extensions by default. Of course, we can overwrite @font-face. The purpose of this issue is to fix it upstream so everyone benefits from it.

[gerrywastaken]

This is an end user comprehension issue.

@chris-purcell Wow, in my case you are correct. It seems I had googled for the problem I was having and ended up on a bug report on the wrong repo. My issue was actually with the addition of version strings to font-awesome in a popular Rails gem. Which it seems, was actually an issue that was fixed 27 days ago:
https://github.com/bokmann/font-awesome-rails/pull/175

[andrenarchy]

@gerrywastaken this is exactly what we're all doing now. It'd be great to have it fixed upstream.

[lt7]

+1

[juanpablof]

+1

[danger89]

Based on the reference from @rmm5t . FontAwesome needs to take this bugfix along, thus somebody needs to merge this change and it will be fix finally in CDN from Bootstrap.

[drzraf]

See also: https://github.com/w3c/preload/issues/68

[IndigoStarfish]

+1

[tagliala]

Done!

[drzraf]

commit ?

[tagliala]

@drzraf please follow #11908

[jocar6562]

src: url('../fonts/fontawesome-webfont.eot?v=4.6.3');
src: url('../fonts/fontawesome-webfont.eot') ;
took out the ?v=4.6.3 not sure what that was for but could see no difference after testing
This worked fine it was the last thing I needed to do now I have speeded up landing page to 625 mil sec johnc