Convert relative URLs to absolute ones pointing to the site domain when processing font URLs

[I3undy]

@Piedone created on Jul 30, 2014:
https://orchardwatcher.codeplex.com/workitem/2

Premises: processed resources should be stored in a remote storage AND using a resource base URL.

There's an issue when there are local source URLs for fonts, e.g.:

@font-face {
  font-family: 'FontAwesome';
  src: url('../Content/fonts/fontawesome-webfont.eot?v=4.0.3');
  src: url('../Content/fonts/fontawesome-webfont.eot?#iefix&v=4.0.3') format('embedded-opentype'), url('../Content/fonts/fontawesome-webfont.woff?v=4.0.3') format('woff'), url('../Content/fonts/fontawesome-webfont.ttf?v=4.0.3') format('truetype'), url('../Content/fonts/fontawesome-webfont.svg?v=4.0.3#fontawesomeregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

These URLs, when the processed resource is saved to the remote storage, will be converted to unified relative, then protocoll-less absolute paths (see ResourceProcessingService.ConvertRelativeUrlsToAbsolute()). This causes a cross-origin error though: such fonts should rather be fetched from the site directly (i.e. their URL re-written as absolute ones, but pointing to the calling site).

The check needed for this could be made whether the current property is under font-face, but this can only be made from ExCSS, when that will be used in Combinator.

Alternatively you could enable CORS on the remote storage. This is a way to do it on Azure Blob storage: http://blog.codingoutloud.com/2014/02/21/stupid-azure-trick-6-a-cors-toggler-command-line-tool-for-windows-azure-blobs/ (on DotNest we'd indeed need to allow * because of the arbitrary site URLs, what is bad...).

The current workaround is to exclude the whole stylesheet containing the font face.