In the fallback case, what constitutes failure?

[jakearchibald]

Map:

{
  "imports": {
    "whatever": [
      "https://server1/img.jpg",
      "https://server2/img.jpg"
    ]
  }
}

Usage:

<img src="import:whatever">

In what ways could https://server1/img.jpg fail? Possibilities:

• Failure to connect.
• CORS failure.
• HTTP 500.
• HTTP 404.
• Response terminates half-way through – this would probably require buffering the response.
• Response is an invalid input to the API (an invalid image in this case) – this would require a lot of per-API changes.

[jakearchibald]

Related:

{
  "imports": {
    "whatever/": [
      "https://server1/whatever/",
      "https://server2/whatever/"
    ]
  }
}

import 'whatever/foo';
import 'whatever/bar';

If whatever/foo falls back to server2, will whatever/bar try server1?

[domenic]

The intention is network error or non-OK status. Maybe MIME type checking if we can figure out a nice way to do that without a layering violation. This is currently a TODO in the spec, for sure.

Great question about fallbacks with "packages". I hadn't really thought that through entirely, but I think ideally we'd cache the whatever/ -> server2 mapping and continue using that for all whatever/-prefixed specifiers.

In general HTTPS -> HTTPS fallbacks are still kind of up in the air, with #76 being one of the bigger blockers.

[littledan]

If MIME type checking is included, that might be nice for incrementally adding more module types over time, where a fallback can be a JavaScript wrapper.

[justinfagnani]

@littledan that's nice, though it requires a round-trip to get the mime-type. It's a great use case for feature detection though.

[littledan]

Yeah, good point; that's probably not a pattern we should encourage.

[guybedford]

To be honest, I would be against network fallbacks exactly because of the latency issue @justinfagnani mentions. Consider also that a large import map wanting to have two servers providing sources, would need two entries for every single module loaded, and would add a round trip of latency for every single one of those modules. The user experience just doesn't seem to quite be there?

On the other hand, sticking to fallbacks only applying to protocols allows the std: polyfill paths, and also allows us to add new protocols to the web in future (such as the decentralized ones under development), in a way that supports a progressive upgrade path.

[michaelficarra]

Can we also clarify that SRI and CSP failures, being checked during fetch, would count as failures for the purposes of fallback?

[domenic]

Those are network errors, so yes.

[jkrems]

I'd like to second the concern raised by @guybedford. Allowing network failures sounds dangerous because it suggests that it's a good "smart client" to handle unreliable backends. Which I'm not sure is helpful / sets people up for success.