Stop Clientlibs From Rewriting Absolute URLs In CSS

[jocamp]

Having some issues with the URLs in our css being rewritten to relative even though we want them to be absolute. One style in particular -

behavior: url(/etc/designs/<appname>/behavior/PIE.htc);

We are developing in CQ5.5 and when the css is compiled it works as expected, the url is still absolute when it gets to the browser. However, when moving to a CQ5.6 server, this style is altered to be a relative url of -

behavior: url(clientlibs/behavior/PIE.htc);

This doesn't seem to be an issue with most files (images), however it doesn't work with the PIE.htc library file. I temporarily worked around the problem by putting the full url to the file -

behavior: url(https://<url>.com/etc/designs/<appname>/clientlibsie/behavior/PIE.htc)

This works but obviously isn't a great idea since that css would have to be changed for our dev, test, and prod servers. Any ideas are appreciated!

Thanks

[msulliva · Accepted solution]

I hope someone else can post a way to prevent the Clientlibs from re-wrtiting CSS URLs.  It seems wrong for a root relative URL to get rewritten.  I think it's a great feature for already relative paths, but if you're explicitly saying something like /etc/designs/pie.htc that's what you mean.

Anyways, we ended up just coming up with a hack in our dispatchers, so basically any request ending in pie.htc would get rewritten to one location, so really you can ask for it from anywhere...

# CSS3Pie Fix
RewriteCond %{REQUEST_URI} !^/etc/designs/pie.htc
RewriteRule ^.*pie\.htc$ /etc/designs/pie.htc [L]

[paul_bjorkstra1]

A solution I have found that works well uses the Sling 404 handler to fake PIE.htc. First, follow these instructions to set up PIE.htc in CQ: https://gist.github.com/msulliva/5971565. Second, create a Sling 404 handler, using instructions found here: http://dev.day.com/docs/en/cq/current/developing/customizing_error_handler_pages.html. Third, ensure your css behavior() points to just "PIE.htc" (not required, just recommended). Finally, at the top of the 404 handler put:
 

if (request.getRequestURI().endsWith("PIE.htc")) { pageContext.forward("/etc/designs/PIE.htc"); // my pie is /etc/designs/pie.htc return; }

This makes the 404 page return the PIE.htc content whenever the request ends with PIE.htc, including but not limited to: PIE.htc, grannysApplePIE.htc, itsMyPIE.htc, and mmmmmPIE.htc. This could be enhanced to handle case insensitive "pie.htc" (not recommended) or to handle just "PIE.htc" (recommended). I have found this will work well until Adobe fixes the fact that clientlibs are rewriting ABSOLUTE urls.

-Paul

Edit 1: A benefit to this solution to other solutions given is that this puts the control of PIE.htc entirely in the development team's hands. If you work in an environment where a server management/maintenance team are the only ones with web server configuration access, then it makes coordination and deployment much simpler.

[jocamp]

Thanks, that's a great idea and definitely seems like it'll work for us. But you're right, there should be a better way to get it to work.

[madhavan_muruge]

Hi,

I am new to CQ, Could you please tell me where we have to add

# CSS3Pie Fix
RewriteCond %{REQUEST_URI} !^/etc/designs/pie.htc
RewriteRule ^.*pie\.htc$ /etc/designs/pie.htc [L]

[Andrew_Khoury]

Hi Everybody, a hotfix was released for this issue a while back.

Here's the hotfix link:

• NPR-3285 - Don't rewrite .htc URL in CSS/LESS.

Full list of available hotfixes:

http://helpx.adobe.com/experience-manager/kb/cq561-available-hotfixes.html

[jocamp]

It depends on what server you're using. The rule msulliva gave as an example looks like its for an apache server. If you use apache, it would be in your httpd.conf