- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 13 Jun 2008 17:45:57 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Jun 13, 2008, at 5:20 PM, Jonas Sicking wrote: > > Maciej Stachowiak wrote: >> On Jun 13, 2008, at 4:56 PM, Jonas Sicking wrote: >>> >>> Hi All, >>> >>> Since I haven't received any feedback on the various straw-men in >>> the "Opting in to cookies" thread, I'll send a full proposal >>> (wrote most of this yesterday, Thomas wrote some opinions on >>> cookies this morning). >>> >>> First off, as before, when I talk about "cookies" in this mail I >>> really >>> mean cookies + digest auth headers + any other headers that carry >>> the >>> users credentials to a site. However i'll just use the term >>> "cookies" >>> for readability, and since that is on the web currently the most >>> common carrier of credentials. >>> >>> So here goes: >>> >>> When loading a resource using access-control associate the request >>> with >>> a "with credentials" flag. >>> >>> When the resource is loaded using an URI which starts with the >>> string >>> "user-private:" set the "with credentials" flag to true. Otherwise >>> set >>> it to false. >> How could an http or https URI start with the string "user- >> private:"? Are you proposing a new URI scheme? > > My proposal is for nesting schemes, so you'd load user-private:http://example.com/address.php That strikes me as distasteful. I would prefer to see a separate includeCrossSiteCredentials parameter on XHR somewhere than to use in- band signalling via the URL, if we feel this is needed. However, I am not sure I understand the purpose of extra client-side opt-in to cookies. Presumably the client side is cross-site and therefore not under control of the server. So if the server is careless about cross-site requests that include cookies or other credentials, then I do not see how an opt-in mechanism on the client side helps at all. regards, Maciej
Received on Saturday, 14 June 2008 00:46:37 UTC