Re: [XHR2] letting authors handle more response codes

"Anne van Kesteren" <annevk@opera.com> wrote:

> 
> Hi,
> 
> I've heard some use cases from authors who want to handle more response  
> codes. For 30x responses and 401 responses. 304 is already addressed by  
> XHR1 by letting the author set various headers himself that will let the  
> user agent pass through the actual response if it's a 304. However,  
> redirects are always transparantly and a 401 will trigger a dialog where  
> the user will have to enter credentials.
> 
> Letting the author handle redirects helps him save bandwidth or lets him  
> inspect the redirect URI to see whether or not to follow it. Letting him  
> handle 401 responses would help in the case where the user entered  
> credentials in the first place and then a request was made using those  
> credentials and they were entered incorrectly. In such cases handling it  
> within your application might give a better user experience than letting  
> the browser handle it.
> 
> For redirects a 'redirect' event is proposed in the draft, but maybe a  
> general attribute that would indicate that the author wants to handle  
> responses himself would be better. Although it seems that only 401 and  
> redirects are affected by this so maybe a redirect and unauthorized event 

> would work...
> 
> Any opinions?

I don't think that introducing a new event for each (currently known!)
response code is a good idea.  Use the readystatechange event instead.

You can't change the behaviour for existing clients, so the client will need
a way of signalling that it wants to see *all* HTTP response codes before
any automatic action is taken.  So, invent a new flag attribute or method
for setting this internal flag.

Then, if this flag is set, fire the readystatechange event as usual for when
the HTTP status code is available, but do this *before* any default actions
are carried out.  If the event is cancelled by any of the event handlers,
then do not carry out any default actions; if the event is not cancelled,
then do carry out default actions.

This way, the client code can choose exactly which codes it wants to see,
and it all works cleanly in exactly the same manner as other default event
handlers.

There may still be a problem with intermediate responses (1xx codes) though
- unless you re-issue the readystatechange each time you've read the
complete HTTP response header?  I don't think that these should ever
propagate outside the HTTP engine, though, so it may not matter.


-- 
Stewart Brodie
Software Engineer
ANT Software Limited

Received on Monday, 6 August 2007 14:08:30 UTC