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

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

From: Brian Smith <brian@briansmith.org>
Date: Tue, 28 Jul 2015 13:24:56 -0400
Message-ID: <CAFewVt5ADbJPZMP1XrA+Y=q1QuuaPTHHB8-banPeSMns5f1OUA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Brad Hill <hillbrad@gmail.com>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, Kristijan Burnik <burnik@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Alex Russell <slightlyoff@google.com>, Ryan Sleevi <sleevi@google.com>
On Mon, Jul 20, 2015 at 9:39 AM, Mike West <mkwst@google.com> wrote:

> Brian, note that this means we really do need the response checking bits
> that you were concerned about earlier.

Is this because the fetch could return an http:// response that was stored
using the cache API by a service worker that forwarded a fetch for an
<img>, <video>, or <audio>? Is there some other reason why response
checking is needed due to allowing fetch to forward mixed content requests
for those types of fetches?

The thing that people working on service workers are most concerned about
is that adding a no-op service worker to a page should not break the page
even if it has mixed content. Allowing service workers to use the cache API
for non-secure documents goes beyond that and IMO adds unnecessary
complexity. it would be simpler and thus better to just not allow a service
worker to cache http:// responses.

In particular, it is unclear to me what prevents a service worker from
returning a response retrieved over http:// in response to an https://
request. Is that specified in the service workers spec, the fetch spec, or
this spec? Where in which spec?

Received on Tuesday, 28 July 2015 17:25:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC