Re: Beacon feedback

Could others also chime in? I'm waiting for feedback on these points
mentioned below.
Arvind


On Sat, Feb 15, 2014 at 7:15 PM, Arvind Jain <arvind@google.com> wrote:

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