- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 13 Feb 2014 18:25:15 +0000
- To: Arvind Jain <arvind@google.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Thu, Feb 13, 2014 at 3:28 PM, Arvind Jain <arvind@google.com> wrote: > OK I've made the change. Could you take one full pass on the spec, and see > if we are good to go for LC. > https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html 1. I don't understand the part of section 4.2 that is not IDL. It seems to contradict the processing model on multiple occasions. Part of it does not, I think, but that should be separated and the authorization bit should be a parameter to Fetch. 2. The processing model has a lot of copypasta. 2a) You define "source origin" and "referrer source" but are not actually using them. 2b) You differ based on global environment without that actually being necessary. 2c) You convert /data/ to code points but forget about /url/. 2d) You invent a concept "asynchronous task" without defining it. (It's not what you want, you just want to return and run the remaining steps asynchronously.) 2e) You invoke "cross-origin request" from CORS (which is obsolete as you know, Fetch is here) without actually defining all the parameters that requires. 2f) You don't deal with closed blobs (unclear yet how that should be done). 2g) For FormData you are concatenating code points and bytes. 2h) Your origin check has a major security bug. You cannot check against the base URL's origin, that can be anything! I'm curious how implementers managed to implement this. I guess they did not actually read the specification and just implemented what they thought it should mean approximately? -- http://annevankesteren.nl/
Received on Thursday, 13 February 2014 18:25:43 UTC