Re: Beacon feedback

Anne,
I'm still working on your comments. A few questions:

1) Re. these two comments of yours:
>> 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.
>> 2h) Your origin check has a major security bug. You cannot check
>> against the base URL's origin, that can be anything!

I'm planning to change Step 8 of processing model (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html#sec-processing-model)
to:

Fetch <http://www.w3.org/TR/html5/infrastructure.html#fetch> url from the base
origin using the POST HTTP
method<http://tools.ietf.org/html/rfc2616#section-5.1.1>
 with transmittedData, encoding, and mime type.

Will this address both the concerns?

2) Re: this comment of yours:
>> 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.

The duplicate bits with the text in processing model are:
a) The sendBeacon<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html#sendBeacon>
method
MUST asynchronously transmit data provided by the
data<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html#data-parameter>
parameter
to the resolved URL
<http://www.w3.org/TR/html5/urls.html#resolve-a-url> provided
by the url<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html#url-parameter>
 parameter.
b) The User Agent MUST use the POST HTTP
method<http://tools.ietf.org/html/rfc2616#section-5.1.1>
 to fetch <http://www.w3.org/TR/html5/infrastructure.html#fetch> the
url<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html#url-parameter>
for
transmitting the data.
c) All relevant cookie headers MUST be included in the request. User agents
MUST honor the HTTP headers (including, in particular, redirects and HTTP
cookie headers).

(a) is a basic definition of the method. So can we keep it here?
(b) is copied in processing model so I can remove it from here.
(c) I assume you mean that since we use "Fetch", this text is redundant: So
I can remove it.
The rest of this section is not duplicate or in contradiction with the
processing model. So I'll keep it as is.

Would that address your concern?

Besides these, I still need to address your comments 2c, 2f and 2g. I'm
working on them.





On Fri, Apr 18, 2014 at 1:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Apr 18, 2014 at 1:38 AM, Arvind Jain <arvind@google.com> wrote:
> > I'll try to get the new draft out by this week. If you have any specific
> > language suggestions for the comments you made, that would help me a lot.
>
> I'm happy to provide guidance and answer questions, but I rather not
> provide text. I would like you to understand why it is wrong and what
> it needs to say so that a) you can more competently maintain the
> specification and b) you can help others.
>
>
> --
> http://annevankesteren.nl/
>