modules, credentials, wtf

[Rich-Harris]

Well I just had quite the adventure. It seems that #458, which addressed the problem of loading client assets from a server that required credentials (identity-aware proxy, in my case), introduces another problem: if you use crossorigin="use-credentials" to fetch modules from a server that has this header...

Access-Control-Allow-Origin: *

...all hell breaks loose. Whereas it was fine when no credentials were being included at all.

At least, I think that's what's happening — need to do some testing to be sure. The error you get isn't exactly written in plain English:

(No 'request' was made for that file, the string 'include' isn't used anywhere, and it's not a 'Script', it's a module.)

Not sure how best to tackle this — ordinarily, Sapper itself is responsible for serving the client assets, so this is really only something that arises in fairly esoteric situations (such as ours, where assets are being moved to a separate location, and the exported pages undergo string replacement therapy). It may become a larger issue when we tackle #437 though.

[Conduitry]

In your case, I imagine it's not possible to have that client js file served with a dynamic access-control-allow-origin header according to what the request origin was, instead of just always returning a *? I'm guessing this is a server you don't have a bunch of control over.

Even if that were not an issue, I've also had some trouble in the past with cached responses which return access-control-allow-origin getting that header also cached - and then if the request is made from a different origin, the browser refuses to use it, because the (cached) access-control-allow-origin doesn't match. Perhaps this could be addressed somehow (is this what the vary header is for?), but ultimately I ended up just going with access-control-allow-origin: * which worked for my case.

I guess this is sort of feeling like a 'welp that's the platform' type of situation. I'm really not sure what could be done here.

[Rich-Harris]

It's true that we don't have control over the server (I mean we could bake banana bread and use it to bribe our engineering colleagues on whatever floor they live on, but for all intents and purposes it's Someone Else's Server). Given that it worked prior to #458 though, it should be possible to just omit the crossOrigin property on the script tag. Making that a middleware option is a possibility. Real edge case though, would be great if there was a default that Just Works