1045222 - navigator.sendBeacon does not set Beacon-Age header

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect)

Description

[David Pattison]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.44 Safari/537.36

Steps to reproduce:

Steps to reproduce the problem:
Using: "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0"
1. Go to dev console
2. navigator.sendBeacon('http://example.com')
3. View headers on remote server. 
4. No Beacon-Age header

I understand that Firefox sends the beacon immediately so the value will always be 0, but this header is useful to identify that this is a beacon and not an XHR Post or some other method.  This can also be useful for network prioritization with load balancers.  

Similar bug with Chrome: https://code.google.com/p/chromium/issues/detail?id=398167

Note: step 3 should be viewable with Net logging/Network Panel, I'll file a separate bug on that.
Alternatively, you can repro by running "nc -l 9000" and then using navigator.sendBeacon('http://localhost:9000') and viewing the results in netcat.


Actual results:

No Beacon-Age header.


Expected results:

Beacon-Age: 0

Comment 1

[Richard Barnes [:rbarnes]]

Attachment: bug-1045222.patch

Sets Beacon-Age to the time (in seconds) between the entry to SendBeacon and when we start the fetch.  So the value of the header should pretty much always zero.

Test upgraded to echo back the Beacon-Age value the server saw, so that the client-side mochitest can check that it was present.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 8464106 [details] [diff] [review]
bug-1045222.patch

Review of attachment 8464106 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

::: dom/tests/mochitest/beacon/test_beaconFrame.html
@@ +63,5 @@
>          var result = JSON.parse(response);
>          
>          is(result.data, data, "Beacon status should match expected.  is: " + result.data + " should be: " + data);
>          is(result.mimetype, mimetype, "Beacon mimetype should match expected.  is: " + result.mimetype + " should be: " + mimetype);
> +        ok(result.age != undefined, "Beacon-Age header must be provided.  is: " + result.age);

How about

is(String(parseInt(result.age)), result.age, "Beacon-Age header must be an integer")?

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

There's a discussion on public-webapps right now about if maybe Beacon-Age should be omitted when the value is 0. Which effectively is all the time in our current implementation.

Comment 4

[Richard Barnes [:rbarnes]]

(In reply to Jonas Sicking (:sicking) from comment #3)
> There's a discussion on public-webapps right now about if maybe Beacon-Age
> should be omitted when the value is 0. Which effectively is all the time in
> our current implementation.

That would be a fine resolution for me.  I'll let this sit for now, then.  Please comment on the bug when that discussion comes to a conclusion.  If we need to send Beacon-Age, then we'll land this patch; otherwise we can just close the bug.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The spec has now been changed to not send Beacon-Age when the age is 0. So we should be conforming as-is.

Of course, it would be great if we had more smarts around delaying sending the beacon when we're not competing for bandwidth from the previous page, but while we still have the radio up. But that's an entirely different bug than this one.

Comment 6

[Richard Barnes [:rbarnes]]

It's times like this when we need the "RESOLVED :: Overcome By Events" state.