Re: [fetch] Requests for http URLs should fail when there's no browsing context (#69)

Funny, we discussed this somewhat extensively between the Chrome networking, security, and service worker teams.

Some of that conversation is captured in https://code.google.com/p/chromium/issues/detail?id=453191 or https://code.google.com/p/chromium/issues/detail?id=448672 or https://code.google.com/p/chromium/issues/detail?id=392409

The TL;DR is that we agree - if the `fetch()` cannot be directly attributed/connected to a client (which it can be in the case of a Window fetch, but at present, cannot be in the case of a Worker fetch), then we block any form of error that we might normally warn on.

@KenjiBaheux wrote all of this up from our meetings, but I see the document is restricted to Googlers. I'm tagging him in to see if there's a sanitized version of the broader discussion, but my attempt to summarize is as follows:

If the `fetch()` is on behalf of a client (and this gets back to the need to tag fetchEvents with the requesting client - https://github.com/slightlyoff/ServiceWorker/issues/119 - and if there are multiple, _at least_ the first client), then we could evaluate the fetch() in the context of that client and that clients' mixed content settings. This means that a fetch() in the case of Window is treated similar to a mixed-content XHR - uses the document/window settings re: mixed content.

If the `fetch()` is not attributable to a client (e.g. a ServiceWorker), then we block the request.

This notably breaks for situations when the SW wants to offer pass-through services, as this means any site using a SW loses the ability to have optionally-blockable content. While 'nice' on one level, this does create a new set of hurdles and inconsistencies that don't strictly seem necessary.



---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/69#issuecomment-118359419