Re: Beacon feedback

Hi Anne,
I've addressed some of your comments and have questions about the others.
Please review (inline below).

Thanks,
Arvind


On Thu, Feb 13, 2014 at 10:25 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> 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.
>

Could you tell me what parts contradict and which parts do you not
understand?


>
> 2. The processing model has a lot of copypasta.
>
> 2a) You define "source origin" and "referrer source" but are not
> actually using them.
>

Removed.

>
> 2b) You differ based on global environment without that actually being
> necessary.
>

Removed.

>
> 2c) You convert /data/ to code points but forget about /url/.
>

Could you please elaborate? I'm not able to see the issue.


> 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.)
>

Removed.


>
> 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.
>

I am not sure how to fix this. The XMLHTTPRequest send() call seems to have
similar language to this. I'll look into it more but if you can clarify
further, that would be helpful.


> 2f) You don't deal with closed blobs (unclear yet how that should be done).
>

Will handle in next pass. (Not sure how to).


> 2g) For FormData you are concatenating code points and bytes.
>

Not sure. Will handle in next pass.


> 2h) Your origin check has a major security bug. You cannot check
> against the base URL's origin, that can be anything!
>

What is the security bug? Again, I review XMLHTTPRequest send() call which
makes a similar check. Please explain what the bug is.


> 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/
>