- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 29 May 2013 13:47:32 -0700
- To: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Cc: ?? Jasvir Nagra <jasvir@google.com>, Anne van Kesteren <annevk@annevk.nl>, Julian Aubourg <j@ubourg.net>, Jungkee Song <jungkees@gmail.com>, John Kemp <john@jkemp.net>, nathan <nathan@webr3.org>, "art.barstow" <art.barstow@nokia.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Ian Hickson <ian@hixie.ch>, "Tab Atkins Jr." <jackalmage@gmail.com>, w3c <w3c@adambarth.com>, ojan <ojan@chromium.org>, Dirk Pranke <dpranke@chromium.org>, mjs <mjs@apple.com>, Tyler Close <tyler.close@gmail.com>, public-webapps <public-webapps@w3.org>, Charles McCathie Nevile <chaals@yandex-team.ru>, "Mark S. Miller" <erights@google.com>
On Wed, May 29, 2013 at 1:19 PM, Hallvord Reiar Michaelsen Steen <hallvord@opera.com> wrote: > I proposed that we >>> modify withCredentials to take three values: "samedomain" (default), "always" and "never". For backwards compatibility with earlier versions of the spec, setting withCredentials=true maps to "always" and withCredentials=false maps to "samedomain". > > But Jonas replied: >> I'm opposed to this change. Trying to modify a boolean value into a >> tristate can't be done fully backwards compatibly. Specifically, I >> don't see a way to define this new behavior in such a way that reading >> from withCredentials behaves in a backwards compatible way. > > Just to clarify if it was unclear in any way: the suggested back-compat measures were limited to what happens when the property is set. I made no attempt at handling getters in a backwards compatible way. The property should return a string reflecting the state it is in, by default "samedomain". Hence, it should not cause any headache or require magic behaviour to *implement* its getter. > > The obvious question is: will that be *sufficiently* compatible with existing content? How much compat pain would the first implementor feel? My gut feeling, for what it is worth, is that compat problems would be limited: > > 1) it is a fairly new API feature, not widely used yet and not even required for many CORS use cases out there. > > 2) its main use case is fulfilled by setting, not reading, the value. > > 2) using CORS for third-party resources that require cookies sounds like a setup that would require some regular maintenance anyway, and require a developer with a pretty good understanding of how things work. If something breaks, evangelizing the right solution may be simpler for these reasons. > > Now, if you are still not convinced this is a good change my plan B is to suggest a "credentialsPolicy" property so we'll find an agreement anyway. :-) But maybe explaining that no quirky getter magic is required helps you see the proposal in a new light? Whatever we're doing here is going to result in a lot of confusion. There's already lots of existing code, tutorials and documentation that treats this property as a boolean property. At best we'd not break existing code, but cause a mix of code/documentation which some treats it as a boolean and others as a string. Hence my statement that there's no way that we can create a clean solution while reusing the existing property. So my objection still stands. Creating a new property seems to have much fewer downsides. / Jonas
Received on Wednesday, 29 May 2013 20:48:34 UTC