Re: Beacon feedback

Hi Anne,
The latest draft is at
https://w3c.github.io/web-performance/specs/Beacon/Overview.html
(as per my last mail).

I removed the duplicate text you cite in your comment (1) below.

Re. (4), I removed the origin check as well per your earlier comments.

Re. (3), the url parser is used but via the "Resolve-a-url" section.

Re. (2), I have not made a change.

Could you please take another look?




On Fri, May 16, 2014 at 6:13 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, May 9, 2014 at 3:35 PM, Arvind Jain <arvind@google.com> wrote:
> > Just checking if the changes I made are in the right direction. Please
> let me know.
>
> Okay, given
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html
>
> 1) "The sendBeacon method MUST asynchronously transmit data provided
> by the data parameter to the resolved URL provided by the url
> parameter." duplicates processing requirements later on.
> Specifications should avoid duplication like that. Same for "The User
> Agent MUST use the POST HTTP method to fetch the url for transmitting
> the data." and "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), but MUST ignore any
> entity bodies returned in the response."
>
> 2) For "To avoid the target confusion security risk, the User Agent
> MUST NOT display HTTP authorization prompts as a result of a
> sendBeacon method call. " you should probably file a bug on Fetch so
> we can make this configurable. Please consider proxy authentication
> when you do that.
>
> 3) In the processing model I think you should use
> http://url.spec.whatwg.org/#concept-url-parser directly for URL
> parsing. You might to throw here if the parsed url's scheme is not
> http or https I think, right?
>
> 4) In the processing model step 8 there should be no need to do an
> origin check. The Fetch Standard takes care of that logic.
>
>
> --
> http://annevankesteren.nl/
>