UPDATE: Despite attempting the suggested "solution," it unfortunately did not resolve the issue. While a typo was initially identified, further testing revealed that it was not the root cause of our problem.
To avoid encountering similar issues when overriding the @font-face, it is crucial to ensure that all formats used in the original @font-face declaration are correctly provided. Failure to do so may result in the browser interpreting it as a separate definition and attempting to download files referenced in both declarations instead of simply overriding them.
Here is the original @font-face definition from FontAwesome's CSS:
@font-face {
font-family: 'FontAwesome';
src: url('../font/fontawesome-webfont.eot?v=3.1.0');
src: url('../font/fontawesome-webfont.eot?#iefix&v=3.1.0') format('embedded-opentype'),
url('../font/fontawesome-webfont.woff?v=3.1.0') format('woff'),
url('../font/fontawesome-webfont.ttf?v=3.1.0') format('truetype'),
url('../font/fontawesome-webfont.svg#fontawesomeregular?v=3.1.0') format('svg');
font-weight: normal;
font-style: normal;
}
When attempting to override this declaration, we mistakenly omitted the "format('svg')" specification:
@font-face {
font-family: 'FontAwesome';
src: url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.eot?v=3.0.1');
src: url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.eot?#iefix&v=3.0.1') format('embedded-opentype'),
url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.woff?v=3.0.1') format('woff'),
url('//ourdomain.com/includes/font-awesome-3.1.x/font/fontawesome-webfont.ttf?v=3.0.1') format('truetype');
font-weight: normal;
font-style: normal;
}
Upon rectifying this by adding the format('truetype') specification, we were able to eliminate the unnecessary requests that were leading to 404 errors.