Align redirect fragment handling with HTTP

[annevk]

This clarifies how fragment conflicts between the request's current URL
and the Location header are resolved (the latter wins if non-null).
This is the same for documents and subresources.

Tests: web-platform-tests/wpt#27575.

HTML change: whatwg/html#6391.

Follow-ups: #1167 and #1175.

Fixes #505.

• At least two implementers are interested (and none opposed):
  • Firefox
  • Chrome
• Tests are written and can be reviewed and commented upon at:
  • Fetch: fragments web-platform-tests/wpt#27575
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1178467
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1690286
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=221897

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[wanderview]

If fetch() is going to return fragments on the Response.url, should the fetch spec also handle fragment propagation on redirects? I don't think it currently does because html spec handles navigation redirects.

[wanderview]

We probably need service worker fixes before this can be implemented. Consider:

1. If a FetchEvent.request.url has a fragment, but Response.url does not, then we want to propagate the request fragment to the new response URL.
2. We need to do something if the FetchEvent request and response URLs have different fragments. I guess Response fragment wins?

[wanderview]

I assume fragments will need to be stored in Cache API. This should be fine in the spec since I believe it just holds Response objects. In practice, though, you may run into situations where a site has old Response values without a fragment in Cache API and new Response objects with a fragment. Not sure there is anything we can do to fix that, but its something to consider.

[wanderview]

These changes seem fine, but see my other comments about other things that need to be addressed before implementation. Thanks!

[wanderview]

FWIW, the bit I implemented for propagating the request fragment to the final response in firefox is here:

https://searchfox.org/mozilla-central/rev/f2ac80ab7dbde5400a3400d463e07331194dec94/dom/serviceworkers/ServiceWorkerEvents.cpp#720-731

[annevk]

I've reduced the scope of this PR (for the second time) to be about redirects only and filed a second follow-up issue, this time for service workers. Who knew fragments would be this much fun.

[annevk]

@davidben @wanderview any concerns with merging this (and the HTML PR) now that the service worker bits have been moved to #1175?

[triple-underscore]

In the location URL algorithm:

If locationURL’s fragment is null, then set locationURL’s fragment to requestFragment.

The variable locationURL is not declared; it may be location.
Assuming location, it can be failure. Thus, the if clause needs to include for checking it.

[annevk]

Thanks, I created #1180 to address that.