W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [XHR2] overrideMimeType in state UNSENT

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 9 Nov 2011 22:53:29 -0800
Message-ID: <CA+c2ei8HUirRkFK8FE_hizODNArhf4rEw13qnrgrnVa76cHfGg@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Andrew Oakley <andrew@ado.is-a-geek.net>, WebApps WG <public-webapps@w3.org>
On Wed, Nov 9, 2011 at 9:39 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 09 Nov 2011 09:30:32 -0800, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wednesday, November 9, 2011, Andrew Oakley <andrew@ado.is-a-geek.net>
>> wrote:
>>> It seems fairly common to call overrideMimeType before open(), but
>>> should throw an InvalidStateError according to current XHR2 editors
>>> draft.
>>> If you search (Google) for overrideMimeType a significant number of
>>> first page results show calling of overrideMimeType before the open
>>> call, so I imagine this will become increasingly common as people
>>> copy+paste.
>>> I don't think this is a particularly problematic thing to allow so can
>>> we please update the spec to allow this?
>> And for the sake of consistency and ease of use, we should allow setting
>> .responseType at that time too.
> Currently open() resets a bunch of a state. If we are going to allow setting
> state before open() is invoked we should rethink how open() ought to work.
> I.e. what it resets and what should be kept as before.
> If we change this it makes sense to change withCredentials and timeout too I
> would say.


> What about setRequestHeader()?

This one is trickier. I would be more concerned about compatibility
given that the function has been around forever and has always applied
only to the current request.

Additionally, since there is no API for getting the current set of
request headers, it makes it hard to inspect an XHR object to ensure
that it's in the correct state before reusing it.

/ Jonas
Received on Thursday, 10 November 2011 06:54:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC