W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2013

Re: Beacon and set cookie

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 17 Nov 2013 23:33:15 -0800
Message-ID: <CA+c2ei9ONL3MBD7-GKuQ_qgesjCcSOD6f9RRAnOVyeQi7zU3Uw@mail.gmail.com>
To: Arvind Jain <arvind@google.com>
Cc: public-web-perf <public-web-perf@w3.org>
On Sun, Nov 17, 2013 at 11:18 PM, Arvind Jain <arvind@google.com> wrote:
> Currently we don't specify how the response to a beacon response will be
> handled. Does the browser:
> a) close connection right after transmitting the data, or
> b) read the response from the server but ignore it, or
> c) read the response header to determine whether to follow a redirect or
> retry on a server busy error, or
> d) do (c) and allow the response to set the cookie on the beacon's url
> domain, but ignore response body.

I would suggest d.

> If (d) is true, will the set cookie be treated as first or third party based
> on whether the url of the document that issued the beacon and the beacon url
> are same or different, respectively?

I'd recommend avoiding defining what's a 3rd party vs. 1st party
cookie. That's not defined by any other web standards as far as I
know. Just let browsers apply whatever cookie policy they want, that's
what they are going to do anyway.

> And second question: do we need to specify that the Referer header will be
> set to the document's uri or is that implicit?

I think that if we refer to the Fetch spec that will define it.

/ Jonas
Received on Monday, 18 November 2013 07:34:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC