Re: XHR LC comments
Anne van Kesteren wrote: - If the URL parameter can be a IRI, then somewhere later on we need to state that it needs to be transformed to a URI before it's put on the wire. Added a transformation step as per 3.1 and also required throwing a SYNTAX_ERR in case of failure (ToASCII operation failure seems the most likely). OK, it would probably make sense then to rename the URL parameter and stored URL accordingly, so that it becomes clear that IRIs are allowed. That being said, I just tested IRIs with IE/FF/Opera/Safari, and they work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have any kind of interoperability here. BR, Julian (*) For the non-ASCII characters in the IRI (reference) /äöü.html, IE sends the raw (ISO8859-1) encoded bytes.
IRI support in XHR, was: XHR LC comments
Julian Reschke wrote: That being said, I just tested IRIs with IE/FF/Opera/Safari, and they work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have any kind of interoperability here. ...so this should probably be covered by the test suite... BR, Julian
Re: IRI support in XHR, was: XHR LC comments
On Wed, 18 Jun 2008 11:35:57 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Julian Reschke wrote: That being said, I just tested IRIs with IE/FF/Opera/Safari, and they work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have any kind of interoperability here. 3/4 doing the same sounds like interoperability is pretty good. There are features discovered where there's 6/4 having different behavior. (Different versions of the same engine.) ...so this should probably be covered by the test suite... Of course, everything should. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: IRI support in XHR, was: XHR LC comments
Anne van Kesteren wrote: On Wed, 18 Jun 2008 11:35:57 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Julian Reschke wrote: That being said, I just tested IRIs with IE/FF/Opera/Safari, and they work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have any kind of interoperability here. 3/4 doing the same sounds like interoperability is pretty good. There are features discovered where there's 6/4 having different behavior. (Different versions of the same engine.) Of course 3/4 sounds better than less than half of the browsers in use :-). Do you really believe anybody is going to use IRIs in XHR if there's no way to make it work in IE? ...so this should probably be covered by the test suite... Of course, everything should. I was mentioning it because MS apparently *does* run the test suite, so adding a test would help ensure the problem appears on their radar. BR, Julian
Re: IRI support in XHR, was: XHR LC comments
On Wed, 18 Jun 2008 11:51:15 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Do you really believe anybody is going to use IRIs in XHR if there's no way to make it work in IE? 3/4 means it's not a Web compatibility problem to support them. No idea what authors will do in the near future. ...so this should probably be covered by the test suite... Of course, everything should. I was mentioning it because MS apparently *does* run the test suite, so adding a test would help ensure the problem appears on their radar. I failed adding a non-ASCII file name through subversion to tc.labs.opera.com so I guess that has to wait until we move the test suite somewhere else. (I tested IRC support somewhere else.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: IRI support in XHR, was: XHR LC comments
Anne van Kesteren wrote: I was mentioning it because MS apparently *does* run the test suite, so adding a test would help ensure the problem appears on their radar. I failed adding a non-ASCII file name through subversion to tc.labs.opera.com so I guess that has to wait until we move the test suite somewhere else. (I tested IRC support somewhere else.) In my test (with Apache) I didn't even create the file. I get 404 when invoking GET on a properly encoded IRI, a 403 when the URL on the wire was malformed (as for IE). Maybe that's sufficient for a test. BR, Julian
Re: IRI support in XHR, was: XHR LC comments
On Jun 18, 2008, at 1:56 PM, Anne van Kesteren wrote: I failed adding a non-ASCII file name through subversion to tc.labs.opera.com so I guess that has to wait until we move the test suite somewhere else. (I tested IRC support somewhere else.) Here is a similar test we have in WebKit, and which doesn't need files with non-ASCII file names: http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/utf8-path.html , http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/intercept/.htaccess . - WBR, Alexey Proskuryakov
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
It seems we are in agreement, mostly :-)
The point of a fictional browser is that it has no market share, no application
built on top of it and thus would not cause customer pain when it changes
implementation.
In the case there isn't clear technical differences, I don't think we should
pick
the right solution based on implementer's cost. Rather We should base it on
customer impact.
A bank with 6000 applications built on top of IE's current APIs simply would
not be happy
if some applications cannot run due to changes in some underlying object model.
And this is not IE's problem alone since the bank simply cannot upgrade or
change the browser,
if all other browsers result in the same breakage.
-Original Message-
From: Ian Hickson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2008 1:51 AM
To: Zhenbin Xu
Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
[EMAIL PROTECTED]
Subject: RE: Further LC Followup from IE RE: Potential bugs
identified in XHR LC Test Suite
On Tue, 17 Jun 2008, Zhenbin Xu wrote:
I am not sure if I understand your question.
responseXML.parseError
has the error information
http://msdn.microsoft.com/en-us/library/aa926483.aspx
Oh, I assumed Sunava meant a conforming Document object was
returned.
A parseError-type object would be what I had in mind, yes. However,
if
we do this, then we should specify it. If we don't specify it, I'd
rather have an exception.
The spec can simply state that a conforming document object is
returned,
which includes out-of-band error information. This is what IE does
today
and is a very reasonable approach that allows rich error information
for
debugging.
I don't believe it is conforming for Document objects to have
parseError
attributes, but I could be mistaken -- is there a spec for parseError?
Even if there isn't, though, I agree that it is a generally good
solution
to the problem, I'm just saying that we should specify it, so that UAs
can be standards-compliant and support it interoperably.
Not really; if the script is expecting an exception, and receives
null
instead, then they'll just get an exception as soon as they
dereference the object, which in almost all cases will be straight
away.
[Zhenbin] I should explain the scenario I talked about. For instance,
if
I am to write a wrapper object myXHR, it makes a difference for me
when
I do the following
myXHR.responseXML
if (!_innerResponseXML)
{
try
{
_innerResponseXML = _innerXHR.responseXML;
}
catch (e)
{
_myexception = e;
return _dummpyResponseXML;
}
}
return _innerResponseXML;
My try catch would not catch null. And the exception would be passed
on
to my callers, which is not what I wanted.
Indeed.
If we are going to spec it to accommodate all existing browsers,
we
would want to make it return null or INVALID_STATE_ERR
exception.
We want interoperable behaviour, so defining it in this way would
be a
bad idea. (I don't really have an opinion either way about
exception
vs null, but it seems that we should just pick whatever is most
commonly implemented, which I'm guessing is what Anne did here.)
Fair enough. So let's pick one.
What is commonly implemented? Is it largest browser market share?
Since the cost to implementations for fixing the problem is independent
of
the size of the user base, it would be based just on the number of
independent implementations.
Is it number of enterprise applications written on top of particular
browser?
All the browsers want to be compatible with the Web, so if there are
mroe
Web sites depending on the exception behaviour than the null behaviour,
then we clearly should do the exception behaviour. And vice versa. Do
we
have any good numbers on this? (That there are widely deployed browsers
that return null instead of throwing an exception tends to suggest that
Web pages don't depend on either behaviour; we'd probably need evidence
to the contrary to decide one way or the other based on compatibility.)
Is it the number of browers, in which case I hope my fictional
home grown personal browser gets a vote :-)
Obviously fictional browsers aren't relevant, since the cost of fixing
a
fictional browser is zero.
From a pure technical point of view, predictably throw exception on
state violations is easier to understand. I hope you would agree
there
is value to change spec for the sake of consistent programming model
(which happens to be the IE model).
Indeed.
Did the spec call out that responseXML returned from XHR should have
equivalent DOM support as UA's object? If it is, that would be a
good
topic for us to debate about.
I believe the spec just says that
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Wed, 18 Jun 2008, Zhenbin Xu wrote: In the case there isn't clear technical differences, I don't think we should pick the right solution based on implementer's cost. Rather We should base it on customer impact. A bank with 6000 applications built on top of IE's current APIs simply would not be happy if some applications cannot run due to changes in some underlying object model. And this is not IE's problem alone since the bank simply cannot upgrade or change the browser, if all other browsers result in the same breakage. For non-Web HTML pages like in this example, solutions like IE's IE7 mode are fine. IMHO we should be concentrating on pages on the Web, not on browser-specific pages -- interoperability isn't relevant when the page isn't intended to run on multiple browsers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
