search

whatwg / fetch

Fetch Standard
https://fetch.spec.whatwg.org/
Other
2.1k stars 325 forks source link

Consider changing Response's url so it includes a fragment #1167

Open annevk opened 3 years ago

annevk commented 3 years ago

I initially bundled this with #505 and I now think that was a mistake. We should consider this separately. We also don't need to change XMLHttpRequest's responseURL as that's a legacy API. An obvious alternative here would be to introduce a separate getter for the propagated fragment if we deem it too risky.

Not exposing this prevents correct usage of fragments in userland. (I'm not sure there is much of that as we haven't seen any complaints to date, but it seems consistent with the extensible web principles to give userland the same capabilities the browser has.)

I will adjust https://github.com/web-platform-tests/wpt/pull/7261 per our decision.

cc @wanderview @yutakahirano @KershawChang @youennf @domenic @jasnell

wanderview commented 3 years ago

I feel like I have seen a couple developer complaints over the years, but I don't have references handy.

yutakahirano commented 3 years ago

I don't have a strong opinion. I would like to maintain my previous position,

I guess that not many pages will be broken. Assuming that, if other browser vendors are fine with the idea I can change the behavior.

stof commented 1 year ago

See https://github.com/hotwired/turbo/issues/825 and https://github.com/hotwired/turbo/issues/211 for reports in @hotwired/turbo that are direct results of this limitation as Turbo cannot know that the final URL being loaded has a fragment.