RE: [beacon] Random comments

Thanks for the feedback Simon. I have made updates based to the spec, https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html, and some comments below.

Eric, Jonas, we had discussed adding text on forbidding HTTP authorization due to target confusion security risks. I added the below text to address that concern. Let me know if you want to make any changes to it: "To avoid the target confusion security risk, the User Agent MUST NOT display HTTP authorization prompts as a result of a sendBeacon method call."


On 12/19/13 3:03 AM, Simon Pieters wrote:
> "The User Agent MUST throw the URLMismatchError exception if the URL cannot be resolved."
> This seems like the wrong exception. Correct is SyntaxError.

I have changed this error to be SyntaxError.

> "The User Agent MUST throw the SyntaxError is data is null."
> This also seems like the wrong exception. If you don't want to allow null, omit the "?" in the IDL 
> and WebIDL will throw a TypeError.

I have removed the "?" in the IDL and removed the SyntaxError.

> The above requirements are duplicated in the Processing Model section.  
> Please remove the above requirements and only throw in the algorithm, as currently the spec 
> basically requires two exceptions to be thrown.

I left the errors only defined in the Processing Model to avoid the duplication.

> The spec uses RFC 2119 keywords in notes. This is bad form. Notes are non-normative. Use words 
> like "might" and "will" instead. If there is something in a note that you actually want to require, don't 
> put it in a note.

I agree that if we want to require a behavior it needs to be in the normative section. I have removed the note on UAs may prioritize the transmission of data lower compared to other network traffic and incorporated it as a MAY clause in the first normative paragraph following the IDL definition.

As for the remaining note on UA making the best effort to transmit data to be an effective alternative to XHR, the note clarifies the behavior already described in the normative section, "The User Agent SHOULD make a best effort attempt to eventually transmit the data." As the note also clarifies that the return value of true shouldn't be confused with the beacon has been transmitted, it's placed near the return value section.

> The mechanics used for obtaining the base URL etc has changed recently in HTML (and XHR), possibly you 
> want to update the algorithm to use it. See e.g. http://xhr.spec.whatwg.org/#dom-xmlhttprequest-open


What parts of that algorithm do you want me to change?

> "These steps may be run even after the document has unloaded." appears a bit toothless since the "fetch" 
> algorithm aborts at step 10 if the document is unloaded. Also I think that the fetching itself is defined in terms 
> of the event loop which doesn't work when the document is unloaded since the event loop ignores tasks from 
> documents that are not fully active. I'm not sure how to fix this but the current text seems like it doesn't work.

This is a tough one and I'm open to suggestions on how we should improve the processing model text. We definitely do want to make sure that we mention that the User Agent may run the task after the document has unloaded, as that's one of the key benefits of the beacon method.

> The algorithm has a branch for worker environment but that is dead code because the IDL only specifies the method 
> on Navigator, not WorkerNavigator.

I've updated the IDL section to add sendBeacon method to the partial WorkerNavigation interface.

Thanks,
Jatinder

Received on Wednesday, 8 January 2014 00:26:53 UTC