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. On Friday, May 9, 2014 5:17:30 PM UTC-7, Steve Orvell wrote: > > This sounds fairly reasonable and could be a big win. > > A pull request is welcome. =) > > > On Fri, May 9, 2014 at 4:44 PM, Jan Miksovsky <[email protected]<javascript:> > > wrote: > >> 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. >> >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/4a515d09-ca29-4bd6-8ccb-4d6171857da3%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/4a515d09-ca29-4bd6-8ccb-4d6171857da3%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/12e41725-5d95-4c97-802c-50c9dda355b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
