Re: RfR: CORS tests - deadline 6 December

On 11/21/12 12:04 PM, Odin Hørthe Omdal wrote:
> You can run the tests with fewer failures here:
>
> http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/testrunner.html

So some caveats.  I only looked at the tests that Gecko fails.  So there 
may well be mistakes in the ones we pass, but we pass them anyway due to 
bugs in Gecko or because the tests are not testing what they mean to 
test or whatever.  There may also be missing test coverage.

1) At first glance, the tests in 
http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/credentials-flag.htm 
are wrong.  In particular, this:

         client.open('GET',
             CROSSDOMAIN + 'resources/cors-makeheader.php?credentials=' 
+ allow,
             false)
         client.withCredentials = true;

will throw in a spec-compliant browser because the withCredentials 
setter throws on sync requests per spec.  See 
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-withcredentials-attribute 
step 4 of the setter steps.  Opera, Chrome, and Firefox all seem to get 
this wrong (with Opera and Chrome throwing on the send() call instead), 
but in the case of Firefox that's an unfortunate recent regression which 
I'll be fixing shortly.  Once I fix it, this test will probably simply 
time out in Firefox, because it's not expecting the exceptions the spec 
calls for.

2) The tests in 
http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/status-preflight.htm 
seem to assume that the readystatechange event firing means the 
readyState is HEADERS_RECEIVED but as far as I can tell it first fires 
in the OPENED state in Firefox, during the send() call.  This last is 
incorrect, and I'll fix it, but the exact firing sequence of 
readystatechange events has nothing to do with CORS per se, so it would 
be better to check the readyState here.

3) 
http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/status-async.htm 
has a similar problem.  It tries to avoid it with this:
             if (client.readyState < client.HEADERS_RECIEVED)
                 return

but of course the RHS of that comparison gets coerced to 0 (because "IE" 
instead of "EI"), and OPENED == 1, so this is triggering in the OPENED 
state.  Hurray for numeric constants with hard-to-spell names!

-Boris

Received on Wednesday, 21 November 2012 20:41:46 UTC