Expand my Community achievements bar.

Learn about Edge Delivery Services in upcoming GEM session
SOLVED

\/etc.clientlibs/clientlibs/granite/utils.js is changing assets request url

Avatar

Level 2

On our website we have added a clientlib to deal with cookies on our page, and our requirement was to put it on the <head> of the page so it can block cookies creation unless the user allow cookies. To do this, we placed it above the granite libraries:

<head>

<script type="text/javascript" src="//external-resource.com/x.x.x/etc/designs/projectux/clientlib/cookie.js"></script>

<script type="text/javascript" src="/etc.clientlibs/clientlibs/granite/jquery.min.js"></script>

<script type="text/javascript" src="/etc.clientlibs/clientlibs/granite/utils.min.js"></script>

<script type="text/javascript" src="/etc.clientlibs/clientlibs/granite/jquery/granite.min.js"></script>

<script type="text/javascript" src="/etc.clientlibs/foundation/clientlibs/jquery.min.js"></script>

...

</head>

We place our library on an external resource (other server). When we did this, we have found an issue with granite in which somehow granite utils changes the paths of some resources in our page. For example,  /etc/clientlibs/templates/projectux/tile.html becomes /x.x.x/etc/clientlibs/templates/projectux/tile.html

I have done some tracking and found out that this is being done by the following lines on granite.js and utils.js:

        /**

         *

         * @private

         */

        self.detectContextPath = function() {

            try {

                if (window.CQURLInfo) {

                    contextPath = CQURLInfo.contextPath || "";

                } else {

                    var scripts = document.getElementsByTagName("script");

                    for (var i = 0; i < scripts.length; i++) {

                        var result = SCRIPT_URL_REGEXP.exec(scripts[i].src);

                        if (result) {

                            contextPath = result[1];

                            return;

                        }

                    }

                    contextPath = "";

                }

            } catch (e) {

                // ignored

            }

        };

        /**

         * Makes sure the specified relative URL starts with the context path

         * used on the server. If an absolute URL is passed, it will be returned

         * as-is.

         *

         * @param {String} url The URL

         * @returns {String} The externalized URL

         */

        self.externalize = function(url) {

            try {

                if (url.indexOf("/") === 0 && contextPath && url.indexOf(contextPath + "/") !== 0) {

                    url = contextPath + url;

                }

            } catch (e) {

                // ignored

            }

            return url;

        };

This is causing 404 on some .html we include and breaking some functionality. Has anyone experienced this before? Can you guide us on how to troubleshoot this?

We are already using AEM 6.4.

1 Accepted Solution

Avatar

Correct answer by
Employee

It looks like there might bug here in how the js of the externalize function deals with protocol-relative urls (i.e. URLs that start with // instead of https:// or http://).  Can you include the protocol in the URL instead?

For example:

<script type="text/javascript" src="https://external-resource.com/x.x.x/etc/designs/projectux/clientlib/cookie.js"></script>

View solution in original post

1 Reply

Avatar

Correct answer by
Employee

It looks like there might bug here in how the js of the externalize function deals with protocol-relative urls (i.e. URLs that start with // instead of https:// or http://).  Can you include the protocol in the URL instead?

For example:

<script type="text/javascript" src="https://external-resource.com/x.x.x/etc/designs/projectux/clientlib/cookie.js"></script>