On Fri, Jul 17, 2015 at 9:33 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Fri, Jul 17, 2015 at 9:06 PM, Mike West <mkwst@google.com> wrote:
> > If Firefox, IE, and Safari have one behavior, and Chrome/Opera have
> another,
> > then it seems like we can claim interoperability in either direction.
> Since
> > that's what the group agreed to do a few months ago, it surprises me that
> > Chrome's SW implementation made a different decision. *shrug*
>
> I guess, but it'd be bullshit. Anyone who wants to ship service
> workers and work with deployed content needs Chrome's behavior. Why
> publish something that's known to be broken?
>
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.
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.
(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?)
-mike