Fetch doesn't respect mode: "same-origin"

[motiz88]

Per the Fetch spec,

A request has an associated mode. [...] "same-origin" [is used] to ensure requests are made to same-origin URLs. Fetch will return a network error if the request is not made to a same-origin URL.

It appears that the polyfill doesn't enforce this. I have created a test page to demonstrate this issue, and how behaviour differs between the native implementation (tested on Chrome) and the polyfill.

I believe it's possible to emulate this on top of XHR by inspecting the various origins at the right times. I'd be happy to dive into the spec and work on a PR (some time in the next few weeks) if a maintainer here signals interest in landing such a change.

[mislav]

Yes, we don't support same-origin.

Even though it could technically be possible to emulate some of these features, such as credentials: 'same-origin' or cache: '...' directives, we choose not to support them because it would inflate the size of this polyfill and make it difficult to test and maintain.

This polyfill never aimed to implement the entire spec; just the parts that cover 80% of all use-cases.

[motiz88]

@mislav Thanks for the quick response!

I see where you're coming from but I do have a couple of points to bring up - I hope you don't mind.

First, you referred to "these features" in aggregate and linked to a generic "caveats" section but did not actually address the specific issue I raised. So just to reiterate, this issue was specifically about mode: "same-origin".

Second, regarding your statement that

This polyfill never aimed to implement the entire spec; just the parts that cover 80% of all use-cases.

Respectfully, can I ask that you make this stance clearer and more consistent in your documentation? Because statements like

fetch isn't able to polyfill the entire standard

and

the aim of this project is not to implement the complete specification; just the parts that are possible to emulate using XMLHttpRequest.

(emphasis mine) make it seem like the criteria for a feature's inclusion are based more on it being feasible (and spec-compliant) than covering "80% of all use-cases" (according to whom?)

And I get that goals change, but even the README for this project at one point stated that

This polyfill is written as closely as possible to the standard Fetch specification at https://fetch.spec.whatwg.org.

All this to say - although you're certainly within your rights to do so, personally I don't think this issue should be dismissed out of hand. Especially when I was offering to do the work.

[mislav]

Respectfully, can I ask that you make this stance clearer and more consistent in your documentation?

For sure! I just pushed some clarifications.

make it seem like the criteria for a feature's inclusion are based more on it being feasible (and spec-compliant)

Definitely; feasibility (as evident by size and maintainability of implementation) is our main criteria.

covering "80% of all use-cases" (according to whom?)

80/20 is an expression rather than a statistic.

Especially when I was offering to do the work.

And we're thankful for the offer! But we also need to be mindful that everything we accept, we will probably need to maintain for years to come. And personally, I'm wary of maintaining security features that are supposed to be browser internals.