Re: [ServiceWorker] Should mixed content always be blocked? (#813)

> > 2) request’s window is an environment settings object (and, therefore, not no-window)

> How can this be persisted to Cache? In most cases the window would be long gone. So storing a passthrough request in Cache would strip is passthrough status.

Why do you need the window to be persisted? You only need it to decide it is `passthrough` or not. And you can not even serialize that a request is a passthrough request because this is something transitional, depending on initiator, window and client.

> But I guess it mostly doesn't matter if it can be persisted. You can do cache.match(passthroughRequest) to return a cached response. It will match the persisted request even though one is "passthrough" and the other is not. The respondWith() mixed content checking will use then use the original FetchEvent.request to determine if its "pass through" when determining if the response is ok.

I think here, the procedure should be to act as if we were performing a `fetch()` from network, so `match()` will run the [_should fetching request be blocked as mixed content_ algorithm](https://w3c.github.io/webappsec-mixed-content/#should-block-fetch) for the passed request (after checking if there was actually a match), and when retrieving the answer, it will run the [_should response to request be blocked as mixed content_](https://w3c.github.io/webappsec-mixed-content/#should-block-response) algorithm (although this would be possibly cached and serialized).

> I think the only problem is if you did a cache.keys() and then used one of the resulting requests in a fetch(). Then it would no longer be treated as passthrough and fail.

I don't see what is the point here. Do you mind to clarify what is the problem in this case?

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/813#issuecomment-173855496