W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2014

Re: [MIX] Consider all CORS requests "active"

From: Jake Archibald <jaffathecake@gmail.com>
Date: Fri, 11 Jul 2014 11:21:19 +0100
Message-ID: <CAJ5xic_+8M9nk1Otd0-LvjBM9qTa-tk8N-Q9uh1w5ry_kbKmgw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 10 July 2014 18:35, Brian Smith <brian@briansmith.org> wrote:

> On Thu, Jul 10, 2014 at 4:08 AM, Jake Archibald <jaffathecake@gmail.com>
> wrote:
> > In ServiceWorker, this means:
> >
> > importScripts('http://...'); - fails
> > fetch('http://...'); - fails
> > cache.add('http://...'); - fails
> >
> > …as they're all CORS dependant.
>
> Anything mixed-content with ServiceWorker should always fail, because
> ServiceWorker would fall under the rule "mixed content is forbidden
> from anything new we add to the web platform." This would include, in
> particular, even <img> requests handled by a ServiceWorker.
>

One of the problems with Appcache is you had to rearchitect your site
around it, ServiceWorker mustn't be like that.

this.onfetch = function(event) {
  // do nothing
};

this.onfetch = function(event) {
  event.respondWith(event.default());
};

this.onfetch = function(event) {
  event.respondWith(fetch(event.request));
};

…none of the above should cause images to fail in cases where they wouldn't
without a serviceworker. The <img> should decide whether it should accept
or deny the response, not the serviceworker. If the HTTP image request
requires cors (<img crossorigin>) it should fail in all 3 cases. If it
doesn't require cors, it should create a mixed content warning in all 3
cases.

Mixed content will be opaque (like all responses to no-cors requests), it's
down to the eventual consumer (<img>, <script>, @font-face etc) whether to
block or allow.
Received on Friday, 11 July 2014 10:21:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC