Resolve Service Worker redirects based on the response #27444
Merged
+168
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We currently resolve Service-Worker-forwarded location headers using the
request. While this matches Firefox, this does not match the spec or
Safari's behavior. Instead, the spec says to resolve the location header
based on the response's URL.
This comes up if the FetchEvent was for /, but the Service Worker
responded with ev.respondWith(fetch("/foo/", {redirect: "manual"})). In
that case, a Location: bar.html header would result in /bar.html by our
version and /foo/bar.html by the spec's version.
Align with the spec. This makes the redirect go where it would have gone
under {redirect: "follow"}. This has two platform-visible behavior
changes:
First, cases like the above will result in a different URL.
Second, script-constructed Response objects do not have a URL list. If
the URLs are absolute, this works fine. If they are relative, those
fetches will now result in a network error. Note Response.redirect()
internally constructs absolute URLs, so those continue to work. This
only affects ev.respondWith(new Response(... location: "bar.html"}})).
Both of these changes match Safari.
Note that, as of writing, the Fetch spec describes this behavior in
terms of a location URL property on the response object. This would
require computing the location URL earlier and preserving it across many
layers, including persisting in CacheStorage. See
https://chromium-review.googlesource.com/c/chromium/src/+/2648648.
Instead, this CL uses the equivalent formulation in
whatwg/fetch#1149. See also discussion in
whatwg/fetch#1146.
Bug: 1170379
Change-Id: Ibb6b12566244fd259029e67787dd7f08edeece9d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2665871
Reviewed-by: Makoto Shimazu <shimazu@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/master@{#850874}