- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 17 Nov 2013 23:33:15 -0800
- 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