On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
wrote:
> So creating a new tri-state property in the XHR spec should also simplify
> integration with the Fetch spec.
Agreed. The question is, if we take it as a given that we're going to
get a new API (that uses futures, deals wit
> > OK then - Anne and others, what do you think about creating a new tri-state
> > xhr.credentialsPolicy property and discouraging usage of
> > xhr.withCredentials ?
>
> I think I'd prefer removing the constructor flag and leaving new
> features to the API for Fetch.
Sorry, I don't understan
On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen
wrote:
> I wrote:
>
>> I would like to see some real code evidence that omitting Origin:
>> and Referer: is necessary too. In theory sites might use them as
>> "credentials" as you say, but in practise I don't see how that can
>> wor
I wrote:
> I would like to see some real code evidence that omitting Origin:
> and Referer: is necessary too. In theory sites might use them as
> "credentials" as you say, but in practise I don't see how that can
> work and be safe on the web.
>
> If we ship XHR with an "anonymous" flag removi
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen <
hallv...@opera.com> wrote:
> Given that many services do (mistakenly or not) use Origin and/or Referer to
> make
> security choices, all these headers along with the cookie header ought to be
> considered "credentials".
Can
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen <
hallv...@opera.com> wrote:
>
> [Minor edit: fixed your true/false typo]
>
> > * If we had a better way of controlling the option to deny sending
> credentials
> > in a way that kept compatibility with legacy webpages (eg. a tristat
[Minor edit: fixed your true/false typo]
> * If we had a better way of controlling the option to deny sending credentials
> in a way that kept compatibility with legacy webpages (eg. a tristate flag
> like
> you suggest in [6]), I agree it would be better than to have two different
> flags
> w
> >> Making a boolean a tri-state with a
> >> default depending on an external variable is also super confusing.
> >
> > To whom?
> It seems confusing to anyone who reads the value.
Good point.
> What would it return
> in the various situations? I.e. before and after .open() has been
> call
