- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 22 Jan 2014 08:46:19 -0800
- To: "doug.turner@gmail.com" <doug.turner@gmail.com>
- Cc: public-web-perf <public-web-perf@w3.org>, Jonas Sicking <sicking@mozilla.com>
On Tue, Jan 7, 2014 at 6:53 PM, doug.turner@gmail.com <doug.turner@gmail.com> wrote: > Hello, > > 1) When using beacon against a cross origin, is it clear that we might need to do a preflight for content types that are not specified by CORS? For example, if you send a ArrayBuffer, we are probably going to need to preflight. This is clear when reading the CORS spec, but it isn’t obviously clear from the beacon spec that there might be two http requests for a beacon — one for the OPTIONS and one for the POST. I am not sure if we can or should relax this or not. Maybe we should be more explicit about which mime types in the beacon specification don’t cause the OPTIONS request. We should simply invoke the normal CORS spec. I happen to think that the CORS spec can probably be relaxed such that it doesn't invoke preflights for the types of requests that we can trigger (unless we add support for setting arbitrary headers) which would be great. But making that change to CORS is a pretty orthogonal task. > 2) In XHR, you can specify if cookies are sent to the cross origin server with withCredentials. What is the thinking we should do with beacon? Do we default to sending cookies? Yes, for beacon we should set withCredentials to true. Not sure if it's worth adding API to change that default to false, but if so that's something that can be added later. / Jonas
Received on Wednesday, 22 January 2014 16:47:17 UTC