Question about 302 redirects

[billiegoose]

Does the spec say how to deal with 302 redirects in import paths? I'm running into this "problem"

If I have a script like this:

import lodash from "https://unpkg.com/lodash"

I see a chain of redirects in the Network tab:

GET https://unpkg.com/lodash-es
> 302 Location: /lodash-es@4.17.4
GET https://unpkg.com/lodash-es@4.17.4
> 302 Location: /lodash-es@4.17.4/lodash.js
GET https://unpkg.com/lodash-es@4.17.4/lodash.js
> 200 OK

Then when the browser (Chrome 61.0.3163.100) resolves the imports of lodash, and sees

export { default as add } from './add.js';

It is making a request to

GET https://unpkg.com/add.js

rather than to

GET https://unpkg.com/lodash-es@4.17.4/add.js

And basically my question is - is Chrome doing the desired behavior and this has been discussed and decided already and I need to change how I'm writing this code? Or is this a potential area where Chrome, or the CDN, or the spec can be adjusted so this usage scenario works?

(finally, I apologize if this isn't the correct repo to create this issue. (It could be a Chrome-specific bug after all?) If you have a better idea about where to file this let me know)

[guybedford]

Yes, this is the way that redirects work for ES modules, by design, and it is a known limitation. In fact it's quite refreshing to see these problems finally happening :)

[guybedford]

Note that the use of a 301 redirect here should resolve the issue.

[billiegoose]

In fact it's quite refreshing to see these problems finally happening :)

I was thinking of that as I was creating this issue. I was thinking, "I've gone way past '1st world problems' haven't I? I'm living in yesterday's future." I feel like I'm reporting an issue with my time travel machine. But you know what they say: the future is already here, it's just not evenly distributed yet.

So obviously we wouldn't want this first redirect...

GET https://unpkg.com/lodash-es
> 302 Location: /lodash-es@4.17.4

... to be a 301, because it goes from a generic package name to the latest version of a package, and that changes over time. But that's OK because that redirect does not change the folder depth. Right? Now this second redirect...

GET https://unpkg.com/lodash-es@4.17.4
> 302 Location: /lodash-es@4.17.4/lodash.js

...does change the folder depth, and therein lies the problem. It sounds like you're saying a 301 redirect here would resolve the resolving issue? I think this change would be a pretty safe change to make, because npm modules are immutable so I don't see why the main entry file for a released version of a module should ever need to change. I'll see if the @unpkg folk can be interested in this.

[billiegoose]

Hang on. Wait a sec. Why can't I reproduce this... (grumble grumble type type)

[guybedford]

A 301 redirect can be cached with a short expiry, in order to match the intent here. Perhaps Chrome updated their implementation to work, always a possibility with this stuff!

[billiegoose]

I don't think it's them. I think it's me. I just can't remember HOW I got into this state. Oh well. I'll leave this open for now and if I can't figure out how to reproduce the problem this afternoon I'll close it.

[mjackson]

A 301 redirect can be cached with a short expiry

Sounds risky, doesn't it? My understanding has always been that once your server returns a 301 there's no telling how various proxies and engines will treat it. It's not hard to imagine someone writing some software that unconditionally caches 301s forever w/out paying any attention to its expiration date.

[guybedford]

Yeah I guess 302 probably is the better option, and the above should actually work regardless of 301 or 302.

[billiegoose]

Alright! I managed to replicate it. But it's a SystemJS specific issue, and maybe I just have something misconfigured? I'll open an issue in the systemjs repo.