custom(er) subdomains to support a full proxy solution

The current proxy solution that the optimizely editor offers is incomplete as it fails to properly deal with relative urls. This causes those resources to be requested relative to the editor and not via the proxy solution.

One way to tackle this issue would be to set up the editor in such a way that you allow customers to have their own custom subdomain (per website). This would allow the editor to intercept these requests within the context of the customer/website and that way be able to proxy it to the correct uri. I bet that in the end this would even simplify the current proxy solution.

If you have any questions, my contact details are in ticket 107001 ;-)

Since the editor loads the page in an iFrame, all contents inside the iFrame are relative to the URL entered into the editor.

"The current proxy solution that the optimizely editor offers is incomplete as it fails to properly deal with relative urls. "

This statement is either false or needs to be qualified to represent the specific scenario(s) where this applies. URLs for background images found in our CSS files are relative pathed and they display just fine in the editor. In this case, the editor handles relative URLs just fine.

@JDahlinANF, I worked with Martijn on this case, so hopefully I can fill in some information here.

The problem occurs when Optimizely defaults by necessity to loading a URL over proxy where resources (e.g. images, stylesheets, scripts) are referenced not by their full source URL, but by a relative url e.g. https://app.optimizely.com/images/someimage.jpg vs /images/someimage.jpg.

When we load such pages via proxy, the resources fail to load because we're looking for them on the optimizelyedit.com (our proxy server) domain. This is something our Product team will be looking into in order to see if there's a more robust solution possible.

@JDahlinANF, you would encounter this when we are unable to load a page via HTTPS or HTTP and default to loading the page via proxy. Usually when the Optimizely snippet is installed, it's possible for the page to load via HTTPS/HTTP, so this is probably why the image is loading correctly in your case.

With Martijn, there was an additional obstacle, which made it impossible for the page to load via HTTPS/HTTP and that's where this issue cropped up.