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

Re: Comments on Mixed Content

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 11 Dec 2014 13:09:10 +0100
Message-ID: <CADnb78jJLFOL7U9M_1e3C-NBpp6ZEuh8MFmh=nVN=bmS2fGtRQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Dec 11, 2014 at 12:51 PM, Mike West <mkwst@google.com> wrote:
> On Wed, Dec 10, 2014 at 2:32 PM, David Walp <David.Walp@microsoft.com>
> wrote:
>> Why is there an inconsistency in the error handing mechanism between #1
>> (XHR) and #3 (Websockets)?
> WebSockets currently throw if the secure flag is false but the calling
> origin is secure (see step #2 of
> http://www.w3.org/TR/2012/CR-websockets-20120920/#the-websocket-interface.
> Anne (CC'd) convinced me that changing XHR to do the same would be a bad
> idea from a compatibility perspective. However, given that WebSockets is
> already throwing, and has been for years, it seems reasonable to simply
> update it's language to match this specification and current concepts (note
> that "entry script" no longer exists).

WebSocket is its own stack. XMLHttpRequest however builds on the same
stuff <img>, <script>, background-image, <link rel=icon>,
sendBeacon(), etc. build on, Fetch. They should have consistent
handling of this stuff and it should be in the network layer. We also
don't want that each new API we introduce that builds on Fetch, e.g.
fetch(), has to consider this and special case Mixed Content behavior.
That's just very bad layering.

Received on Thursday, 11 December 2014 12:09:37 UTC

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