search

whatwg / loader

Loader Standard
https://whatwg.github.io/loader/
Creative Commons Zero v1.0 Universal
609 stars 45 forks source link

Handling of symlinks / redirects #124

Open guybedford opened 8 years ago

guybedford commented 8 years ago

How would this spec plan to implement 301's and symlinks?

Ideally we should ensure that there is alignment with the way the HTML module tag is implementing this based on its requestURL and responseURL. Is this parity important?

guybedford commented 8 years ago

Ideally a redirect could just be a transparent proxy module in the registry, like an export * with default?

caridy commented 8 years ago

I'm not sure yet if this is important or not, without thinking too much about it, I think parity is important because we don't want to attempt fetching an already existing entry from the registry, and preserving the state-fullness of the module instance itself, instead of having two module records for it.

As for the transparent proxy, a "proxy" is probably the wrong term here, just remember we can have the same ModuleStatus object twice in the same registry :)

domenic commented 8 years ago

HTML's current proposed strategy is to use the request URL as the key in the memoization map. The following are cases that need to generally be considered:

(maybe I am missing some, but I think all problematic cases can be reduced to these...)

The consequence of this in HTML right now is that in case A, given a module that imports both request1.js and request2.js, there will be two distinct module records and the side effects will happen twice. Case B will always evaluate response1.js and response2.js will never be fetched or evaluated.

This seems somewhat OK. You might envision a scheme that tries to avoid the duplicates in case A, but I think it screws up case B. And you can argue that if an author actually writes their code to do import "./request1.js" and import "./request2.js" they should not be surprised if this gives them two different module records.

As a separate issue, HTML uses the response URL as the base URL for resolving relative specifiers. This seems necessary; using the request URL would end up just weird. See https://github.com/whatwg/html/pull/443#issuecomment-170958512. This might seem inconsistent with using request URLs as keys, but in the end I think they're pretty unrelated, and the behavior is not surprising.

guybedford commented 8 years ago

As a separate issue, HTML uses the response URL as the base URL for resolving relative specifiers. This seems necessary; using the request URL would end up just weird. See whatwg/html#443 (comment). This might seem inconsistent with using request URLs as keys, but in the end I think they're pretty unrelated, and the behavior is not surprising.

If responseURL is being used as the relative resolution URL, that is something that is not captured by this spec at all, and would need to be integrated as a new feature here in order to provide parity with HTML.

The request URL is the identifier in this spec as well, so there would already be the same behaviours for A and B in the first examples.