On Wed, May 29, 2013 at 1:19 PM, Hallvord Reiar Michaelsen Steen <[email protected]> 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
