Re: [XHR] anonymous flag

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