W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [XHR] Status Update

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 10 Aug 2010 08:13:44 +0200
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.vg7kw6f664w2qv@anne-van-kesterens-macbook-pro.local>
On Tue, 10 Aug 2010 00:37:58 +0200, Maciej Stachowiak <mjs@apple.com>  
> On Aug 9, 2010, at 6:05 AM, Anne van Kesteren wrote:
>> As a result of working on the test suite I found a few minor issues  
>> that would be nice to resolve (I'm not particularly interested in the  
>> solution to each of these problems, but I thought I would propose one  
>> in order to move things forward). I filed these bugs on them:
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322
> I agree with this change.
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10323
> I'll have to think about this one. It does seem like a feature addition,  
> and it's late in the game for that. It's not totally clear to me that  
> responseXML is the best way to expose parsing of HTML documents, since  
> there is no way to feature test for it. CR is probably too late to be  
> adding features, especially when it's not 100% clear it is the right  
> design.

Fair enough. I'm generating XMLHttpRequest and XMLHttpRequest Level 2 from  
the same source document and was trying to get rid of some of the (in my  
view) unneeded differences with some of these comments. I'll mark this bug  

>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324
> Agree, assuming there is no Web compatibility issue.
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325
> Agree.
>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326
> How do implementations currently behave in this case?

It seems most implementations actually allow it (commented in the bug). (I  
have not written tests for authorization yet.) But I believe Internet  
Explorer throws and per RFC 2616 it is not even part of http URLs.

>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327
> I'm not sure what the current proposal is here. I don't think a scheme  
> whitelist is right.

The current proposal is described in the last comment. Namely to allow  
everything (nothing is "unsupported" as far as open() is concerned) and  
let it be a network error in the request layer. (They will be cross-origin  
and not support CORS unless we really want them to work.)

>>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328
> Seems ok to me, if there is no compatibility issue.

Not mentioning it at all is probably safest.

> Which of the changes above would require us to drop back to Working  
> Draft and have another Last Call? Any of them, or just a subset?

The one that changes conformance is not throwing for non same-origin URLs.  
That is also the most important. I do not think we can consider it just a  
"bug fix" but we could discuss it with the Director and see if it is ok.

Relevant URLs:


> If we do have another Last Call, I would prefer to go to CR again and  
> not short-circuit the process. I place more value on careful process  
> than on getting to REC quickly.

We could only go to PR if we met the CR requirements. Essentially you get  
a zero-day CR. If we actually have met the requirements (of which two  
fully compliant implementations will be the most tricky one) there is not  
much reason to issue a CR. I'm fine with doing it anyway though, but lets  
table this for then :-)

Anne van Kesteren
Received on Tuesday, 10 August 2010 06:14:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC