- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 11 Dec 2014 13:09:10 +0100
- 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. -- https://annevankesteren.nl/
Received on Thursday, 11 December 2014 12:09:37 UTC