Re: CfC: Mixed Content to PR; deadline July 6th.

On Sat, Jul 18, 2015 at 1:30 PM, Mike West <mkwst@google.com> wrote:
> It's not clear to me that this is the case. That is, it's certainly true
> that an application that can't or won't fix mixed content issues would have
> a difficult time caching insecure content in a service worker. I don't think
> it follows that allowing mixed 'no-cors' requests is necessarily the right
> way to address the issue, nor is it clear that allowing such fetches is
> safe.

Agreed, but if that's what Chrome is shipping other browsers will have
a hard time doing anything different.


> Making requests directly in response to a page's insecure request seems
> reasonable: we know that the request is going to be used in an
> "optionally-blockable" way, otherwise we wouldn't allow the request to get
> to the SW. Making insecure requests at arbitrary times and using those
> responses as responses to otherwise secure requests worries me, and it's not
> at all clear to me that they're _necessary_, though I certainly understand
> that they're appealing to developers.

For this reason I introduced a request's window concept. I copied you
on the discussion, but you were not really available the past couple
of weeks. fetch() copies the window from any request passed in, but by
default it'll be "no-window" for service workers. So unless you got
hold of a request (e.g., through the fetch event), you'll be out of
luck.

And I think Mixed Content should fail unless there is a window, since
otherwise there is no UI where icons can be changed.


> (Note also that in my ever so brief (and probably incompetent)
> experimentation, I'm getting mixed content errors when doing anything other
> than a passthrough fetch for insecure content. Maybe I misunderstood Alex,
> or he misunderstood me?)

If by passthrough you mean fetch(event.request) that'd make sense to me.


-- 
https://annevankesteren.nl/

Received on Sunday, 19 July 2015 16:09:07 UTC