- From: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Date: Wed, 29 May 2013 22:19:31 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- 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>
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? > At least > not while keeping the API sane. > > I'd instead prefer to define a new property. > > / Jonas
Received on Wednesday, 29 May 2013 20:20:59 UTC