W3C home > Mailing lists > Public > public-webapi@w3.org > August 2007

Re: [XHR2] letting authors handle more response codes

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 06 Aug 2007 16:45:27 +0200
To: "Stewart Brodie" <stewart.brodie@antplc.com>
Cc: public-webapi@w3.org
Message-ID: <op.twm691it64w2qv@annevk-t60.oslo.opera.com>

On Mon, 06 Aug 2007 16:27:40 +0200, Stewart Brodie  
<stewart.brodie@antplc.com> wrote:
> "Anne van Kesteren" <annevk@opera.com> wrote:
>> On Mon, 06 Aug 2007 16:07:16 +0200, Stewart Brodie
>> <stewart.brodie@antplc.com> wrote:
>> > I don't think that introducing a new event for each (currently known!)
>> > response code is a good idea.  Use the readystatechange event instead.
>> It's not about currently known. It's about response codes for which the
>> XMLHttpRequest object has special behavior. That's a limited range of
>> response codes (listed in my opening post).
> Are you seriously considering special casing each individual response  
> code as and when a case is made for it being useful for the client?

You're missing that 1xx is not relevant and that 2xx, 304, 4xx (with the  
exception of 401) & 5xx are already addressed. However, agreed that in  
theory having separate events might not scale very well. (Although it's  
not really separate events, all redirects for instance would be grouped  

> I think that to do that is just asking for ongoing trouble.  Just make it
> generic: create a new event if you don't want to re-use the already
> overburdened, overloaded and Byzantine readystatechange event. It'll be
> easier to implement and forward compatible, so the problem'll be solved  
> for all time.

That might be another option, yes. Options so far:

   1. Single event that is dispatched for redirects, 401 scenario's etc.
      that can be cancelled to let the script author handle it.

   2. Separate events for redirects and 401.

   3. Boolean attribute that you set before sending which indicates
      whether to follow redirects and whether to let the user agent
      handle 401.

In case of the third option the response would be treated similarly to 200  
or 410 and you would use .status to figure stuff out. Something like  
client.controlResponse = true. Even in that case I would have 304 still be  
handled in its special way I think as its confusing to most authors and  
"normalizing" it to 200 makes sense.

Anne van Kesteren
Received on Monday, 6 August 2007 14:46:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:57 UTC