On Sun, Nov 10, 2013 at 12:34 AM, Doug Turner <doug.turner@gmail.com> wrote: > A couple questions about the spec: > > 1) In section 4.2, it talks about the Cross-origin policy. I am wondering > why there is a difference between PUT and the other verbs. It is probably > an obvious answer that I am not seeing. > PUT is not a "simple method" [1], which means it would require a preflight request before the actual beacon is dispatched -- this only applies to cross-origin requests. [1] http://www.w3.org/TR/cors/#simple-method > 2) I think we should discuss what sort of HTTP headers must be sent with > the Beacon. Suppose that we want to send the cookie header along with the > beacon. If the cookie values change between the time the beacon is sent > and the time we get around to actually making the http request, is it > ‘okay’ to use new value? Maybe we can ignore all of this, and make these > beacon requests “sandboxed” such that there is no cookie information sent. > Thoughts? > a) We definitely can't ignore cookies.. Cookies should be sent by default. b) We should send cookies as they were when sendBeacon() is called by the app. > 3) Assuming that we are going to send cookie information… Why can’t the > |data| parameter of sendBeacon be null? I don't see any reason why we'd > care very much of the developer wants to send a beacon back with empty > content. > Yeah, we need to allow this to enable GET beacons also.
Received on Sunday, 10 November 2013 16:25:10 UTC