Coaxing HTML Imports polyfill to resolve paths relative to a given URL

[Jan Miksovsky]

I want to allow a web server to handle an HTML import with a redirect and am running into an issue in the polyfill.

Support a page wants to include a component at /old/stuff/test-element.html:

<link rel="import" href="/old/stuff/test-element.html">

The server wants to fulfill this request with a redirect that points to /new/test-element.html. The latter file contains the desired element definition. When the above import is requested, the browser silently gets the 301/302 redirect to /new/test-element.html, retrieves that file, and goes about its business.

This mostly works, but I've hit a snag when the referenced test-element.html file includes a relative path. Suppose the element itself wants to load a script at "../script.js". Under native HTML imports, this relative path is applied to the redirected location, /new/test-element.html, resulting in the final path of /script.js. For my purposes, that's exactly what is expected and desired.

Under the polyfill, however, the JavaScript layer doesn't know about the redirect, so it tries to apply the relative path to the original location. This produces the final path of "/old/stuff/script.js". In my particular redirect use case, this causes things to break. The same thing goes for any call within the component to this.resolvePath(). It's my understanding there's no way at the XMLHttpRequest level for the polyfill to know about the redirect, so there's no way for it to handle paths relative to the new (redirected) location.

If there's no existing way to finesse the problem, I was wondering if the HTML Imports polyfill could define some convention for handling this. Suppose the server included in the response for the redirected file an additional header field ("Polyfill-Import-Location: /new/test-element.html") indicating the location that should be used for polyfilling access to relative paths found in that file. This would be a hint for the HTML Imports polyfill, in much the same way that polyfill-next-selector, etc., are hints to the Shadow DOM polyfill.

[Steve Orvell]

This sounds fairly reasonable and could be a big win.

A pull request is welcome. =)

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/4a515d09-ca29-4bd6-8ccb-4d6171857da3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jan Miksovsky]

I've filed https://github.com/Polymer/HTMLImports/issues/61 to track this proposal. It would be hugely helpful.

I'm willing to take a shot at a pull request, although I've had difficulties in the past trying to get set up to hack on Polymer. I can try to make another go at that, and post questions as they come up.