Re: Beacon feedback

Hi Anne,
Could you please answer my follow up questions? I need some clarification
on your comments.

Thanks,
Arvind


On Sat, Feb 22, 2014 at 8:44 PM, Arvind Jain <arvind@google.com> wrote:

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