Re: XHR tests

On Mon, 25 Feb 2008 15:56:25 +0100, Anne van Kesteren <annevk@opera.com>  
wrote:
>>> http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/003.htm
>>
>> This is more like a demo than a test case, it doesn't return a  
>> pass/fail to the framework and it doesn't really test what TITLE  
>> claims. (What it *does* test is that readyState is 1 in the first event  
>> sent when you call send() on a synchronous request..). Anne, please fix  
>> this test and figure out what you meant to test with this script.

This is fixed now. responseText no longer throws and will always return a  
DOMString.


>>> http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/006.htm
>>
>> Tests getAllResponseHeaders() output if the request ends up in an  
>> endless redirect loop. Assumes that it should return null.

It now tests for the empty string. getAllResponseHeaders() will always  
return a DOMString.

getResponseHeader() will still return null for this case as it already has  
another case where it returns null. Returning null seems more natural  
therefore and I don't think it will cause any harm if implementations  
change that.


>>> http://tc.labs.opera.com/apis/XMLHttpRequest/send/003.htm
>
> This one passes in Firefox 3 and IE7. Though the alert() statement  
> should probably be removed.

Removed.


>>> http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/011.htm
>>
>> Same as 010 except it tests for first argument being undefined and IE  
>> doesn't actually throw here.
>
> Should we change the API so that undefined stringifies as IE does? Does  
> IE stringify for the value too? And what does it do for null?

We can fix this when the Web IDL spec is done.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>