passthrough service worker can break sites using redirected stylesheets

[wanderview]

Consider a site a.com which has a stylesheet link to a.com/foo.css. But a.com/foo.css redirects to a.com/style/foo.css. Inside foo.css there is a relative background-image url to ./bg.jpg.

With no service worker in play, the site will end up loading a.com/style/bg.jpg.

If there is a passthrough service worker that does nothing but e.respondWith(fetch(e.request)); then the site will try to load a.com/bg.jpg. This is because the redirect to a.com/style/foo.css is eaten by the SW fetch() call.

Should FetchEvent.request for stylesheet loads have RequestRedirect set to "manual"? This would ensure that the stylesheet always sees the final URL and properly loads the correct relative sub-resources.

cc @jakearchibald @slightlyoff @annevk

[wanderview]

I guess workers have the same problem. If a.com/worker.js is redirected to a.com/scripts/worker.js and then does an importScripts('./lib.js'), then the relative URL for the sub-resource is broken again. With a pass-through service worker it tries to load a.com/lib.js instead of a.com/scripts/lib.js.

Also, @annevk tells me on IRC he does not think manual redirect is the answer here.

[annevk]

It would kinda suck to change this, but using the response's url (except for synthetic responses) and not override it with the request's url does seem a lot less surprising as the default. Especially now that we changed so many other aspects of fetch() to not break defaults.

[wanderview]

cc @jungkees

[wanderview]

I guess this is nothing new as its whats discussed in #607. The overrideRequestURL concept from that issue might work here.

[annevk]

Well, we'd want the inverse of that to not break defaults.

[jungkees]

Fetch will remove the step setting request url to response url when there exists response url. This will solve both synthetic response scenario and navigation scenario.

[jakearchibald]

If synthetic we override (because otherwise it's undefined)

[annevk]

Only for synthetic responses (when there's no response url), the response will assume the request url.

[annevk]

(Navigation will therefore not be affected since it doesn't look at the response url, but stylesheets will be fixed and workers will change too.)

[wanderview]

Note, this largely makes current spec stuff for opaque tainting just work as well. Legacy code largely would have looked at final URL to determine cross-origin no-cors status.