Re: [XHR2] overrideMimeType in state UNSENT

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.

Agreed.

> 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