Open mbolesta opened 12 years ago
I raised the same issue a few weeks back, see the open issue: https://github.com/mwrock/RequestReduce/issues/177
The reason the URL's need to be re-written has nothing to do with image spriting, but because the CSS file is now served from a different location your relative links to background images would no longer be valid - I personally like this as it allows be to keep my original css cleaner but am not a fan of the URL being appended.
Anyway, see the above ticket and hopefully Matt will have a fix for this soon. In the meantime you can set "contentHost" in config to the https address to "fix" the error, or use the suggestions provided in the other ticket until the update is released.
https://github.com/mwrock/RequestReduce/wiki/RequestReduce-Configuration-options
I can't use ContentHost as there is not one value I can set that to for my production environments. For now I was able to work around this with regex in a custom minifier I defined.
Similar issue to the one I have then since this is deployed from a multisite CMS solution (one codebase, many URL's)... I've not done anything about it right now but it will become any issue very soon.
In our production environments we use HTTP behind our firewall. RequestReduce makes all urls inside a CSS file absolute so I need to transform them back to relative or switch them to HTTPS to avoid the browser unsecure content warnings.
The issue I have is that RequestReduce doesn't call UrlTransformer when processing the CSS resources. From what I can determine in the source they are made relative in the CssReducer.ProcessCss method.
I should note I have ImageSpritingDisabled set to True. Is the spriting the reason the urls need to be absolute or is this just a bug not respecting UrlTransformer?
I can set ContentHost and it does work then - but I'd rather not as that can change in our production environments.