Re: responseXML/responseText exceptions and parseError
Ian Hickson wrote: On Wed, 18 Jun 2008, Zhenbin Xu wrote: [Zhenbin Xu] Regardless what different browser does today, rich parsing error is an important feature for developers. I have found it can pinpoint the exact problem that otherwise would have been difficult to identify when I sent incorrectly constructed XML file. Mozilla shows the XML error in its error console, which seem more useful than exposing the error to script, really. (I expect other browsers do the same but I haven't checked as recently.) That's useful, but IMHO not nearly as useful as giving the script code the ability to access the information. Sometimes errors happens in the absence of the developer, and it's useful to have an easy and automatable way to get the diagnostics. BR, Julian
Re: responseXML/responseText exceptions and parseError
timeless wrote: generally what i've seen is that exposing some information about a parse error to a script is a great way to enable data leaks to a malicious application. On Thu, Jun 19, 2008 at 11:19 AM, Julian Reschke [EMAIL PROTECTED] wrote: Could you please provide some more information or give an example about when this would be the case? this is the replacement spec which doesn't support this feature (which also implies that people might have had a reason): http://dev.w3.org/csswg/cssom/#the-cssstylesheet Statements that were dropped during parsing can not be found using these APIs. ... Can you provide an example where providing *XML* parse error information within *XHR* would be problematic? BR, Julian
Re: responseXML/responseText exceptions and parseError
Julian Reschke wrote: timeless wrote: On Thu, Jun 19, 2008 at 1:09 PM, Julian Reschke [EMAIL PROTECTED] wrote: Can you provide an example where providing *XML* parse error information within *XHR* would be problematic? i really shouldn't have to. imagine a document that is not CSS and is not XML. now imagine an api that lets you try to load it as css. imagine that this api exposes a dom object that describes *any* information from that document in the case that it fails to parse as css. basically it meant that you can interrogate pages that you weren't supposed to be able to look at to get information you weren't supposed to have. now replace 'css' with 'xml'. The logic still applies. And yes, I understand you'll wave hands about this is a trusted application. I don't care. If it's a trusted application, then I trust it not to make mistakes and to have ways to verify the information server side before it's ever sent on any wires. But you already can read the unparsed content using responseText, no? Where's the leakage then? Exactly. The problem with bug 35618 is that CSS can be loaded from a 3rd party site without that site opting in. In this case providing parsing error information could result in leakage of private information. Though really, just the loading of the CSS is an information leak. However it has been deemed unlikely that someone will put private informaion into CSS rules. There would be no risk of information leakage to provide parse error information for same-site CSS loads. Likewise, there is no risk of information leakage to provide parse errors for same site XML loads, or cross-site XML loads where the 3rd party site has opted in. / Jonas
Re: responseXML/responseText exceptions and parseError
Julian Reschke wrote: Could you please provide some more information or give an example about when this would be the case? Here's a simple past example, if I understand your question correctly. One can set an onerror handler on Window that will trigger if an exception is thrown and not caught, and will also trigger on script parsing/compilation errors. For the latter case, the offending line of script is included in the exception object. Now consider the following HTML page: script src=target.html/script Since most likely target.html is not actually valid JS, there will be a parse error, and the error object will contain the text on the line in question. For what it's worth, Gecko will now only include the text if the script the error is in and the onerror handler are same-origin. Until we started doing that, there was a cross-origin information leak. -Boris
RE: responseXML/responseText exceptions and parseError
-Original Message- From: Julian Reschke [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 12:13 AM To: Ian Hickson Cc: Zhenbin Xu; Jonas Sicking; Anne van Kesteren; Sunava Dutta; IE8 Core AJAX SWAT Team; public-webapps@w3.org Subject: Re: responseXML/responseText exceptions and parseError Ian Hickson wrote: On Wed, 18 Jun 2008, Zhenbin Xu wrote: [Zhenbin Xu] Regardless what different browser does today, rich parsing error is an important feature for developers. I have found it can pinpoint the exact problem that otherwise would have been difficult to identify when I sent incorrectly constructed XML file. Mozilla shows the XML error in its error console, which seem more useful than exposing the error to script, really. (I expect other browsers do the same but I haven't checked as recently.) That's useful, but IMHO not nearly as useful as giving the script code the ability to access the information. Sometimes errors happens in the absence of the developer, and it's useful to have an easy and automatable way to get the diagnostics. BR, Julian [Zhenbin Xu] Agree :-) One less dependency.
RE: responseXML/responseText exceptions and parseError
-Original Message-
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 19, 2008 1:24 AM
To: Zhenbin Xu
Cc: Anne van Kesteren; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
[EMAIL PROTECTED]
Subject: Re: responseXML/responseText exceptions and parseError
Zhenbin Xu wrote:
Inline...
-Original Message-
From: Jonas Sicking [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2008 3:37 PM
To: Anne van Kesteren
Cc: Zhenbin Xu; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
[EMAIL PROTECTED]
Subject: Re: responseXML/responseText exceptions and parseError
Anne van Kesteren wrote:
On Tue, 17 Jun 2008 10:29:12 +0200, Zhenbin Xu
[EMAIL PROTECTED] wrote:
Technically because all other XHR methods/properties throw
exceptions
in case of state violation, exception for responseXML/responseText
is
better.
The reason these don't throw an exception anymore is actually
documented
on the public-webapi mailing list. Nobody else provided additional
information at the time:
http://lists.w3.org/Archives/Public/public-
webapi/2008Feb/thread.html#msg94
Regarding parseError, since the parseError object is not part of
DOM
Core and nobody but Internet Explorer supported it, it's not part
of
XMLHttpRequest.
Agreed.
[Zhenbin Xu] Regardless what different browser does today, rich
parsing
error is an important feature for developers. I have found it can
pinpoint
the exact problem that otherwise would have been difficult to
identify when
I sent incorrectly constructed XML file.
And given that the goals is to define a useful spec for future
XHR implementations, we should define how rich parser error is
surfaced instead of omitting it because nobody but IE supported it.
It is even more important we define it in the XHR spec because it is
not
part of DOM Core. Otherwise such a key piece would be lost and we
will
have diverging implementations.
The goal of XHR Level 1 was to get interoperability on the feature set
that exists across the major implementations of XHR today, so I don't
think parse error information fits the bill there, but it sounds like a
great feature to look into for XHR Level 2.
[Zhenbin Xu]
If we change DOM Core to say that documents with a
namespace well-formedness violation are represented by an empty
Document
object with an associated parseError object I suppose we could
update
XMLHttpRequest to that effect.
If we return null now people will use that to check for well-
formedness
checks. If we in the next version of the spec then said that an
empty
document with .parseError set should be returned those pages would
break.
So if we are planning on doing the parse error thing then I think we
should define that an empty document is returned.
Though I think it's more friendly to JS developers to return null.
Otherwise they have to nullcheck both .responseXML as well as
.responseXML.documentElement in order to check that they have a
valid
document.
And if I understand it right IE would have to be changed to be
complient
with the spec no matter what since they currently return a non-empty
document.
/ Jonas
[Zhenbin Xu] IE does returns an empty document.
responseXML.documentElement
is null but responseXML is not null.
A typical readyState handler can be written this way:
xhr.onreadystatechange = function()
{
if (this.readyState == 4 this.status == 200)
{
var x = this.responseXML;
if (x.parseError.errorCode != 0)
{
alert(x.parseError.reason);
return;
}
alert(x.documentElement);
}
}
I don't see why this is not friendly. It is more comprehensive and
gives
more information than a simple null check, which contains no
information
about what exactly is the parsing error (e.g. which open tag doesn’t
match
which end tag, etc.).
Won't that throw when XHR.responseXML is null, such as when the
mime-type is something completely different from an XML document?
But I absolutely agree that a null check does not give enough error
information to usefully do debugging. I was merely saying that a null
check should be enough to check for if parsing succeeded. The above is
probably not what you would want to do on an end user site since a user
won't care which end tag was not properly nested.
/ Jonas
[Zhenbin Xu] The way it was designed is that responseXML is always not null once
it is in OPENED state. I don't think IE currently give out rich error
information
about mimetype mismatch but the design allows it to be exposed on responseXML,
if
necessary.
It is still prudent to do the above check on end user site because it is more
robust
Re: responseXML/responseText exceptions and parseError
Zhenbin Xu wrote: [Zhenbin Xu] Regardless what different browser does today, rich parsing error is an important feature for developers. I have found it can pinpoint the exact problem that otherwise would have been difficult to identify when I sent incorrectly constructed XML file. And given that the goals is to define a useful spec for future XHR implementations, we should define how rich parser error is surfaced instead of omitting it because nobody but IE supported it. It is even more important we define it in the XHR spec because it is not part of DOM Core. Otherwise such a key piece would be lost and we will have diverging implementations. The goal of XHR Level 1 was to get interoperability on the feature set that exists across the major implementations of XHR today, so I don't think parse error information fits the bill there, but it sounds like a great feature to look into for XHR Level 2. [Zhenbin Xu] Did something happen to your reply here? [Zhenbin Xu] The way it was designed is that responseXML is always not null once it is in OPENED state. I don't think IE currently give out rich error information about mimetype mismatch but the design allows it to be exposed on responseXML, if necessary. Ah, good to know. I'm not particularly a big fan of this design, feels more logical to me to not return a document object if no document was sent. But I guess it depends on how you look at it. / Jonas
Re: responseXML/responseText exceptions and parseError
Zhenbin Xu wrote: Sorry I accidently deleted part of reply. Inline... -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 2:17 PM To: Zhenbin Xu Cc: Anne van Kesteren; Sunava Dutta; IE8 Core AJAX SWAT Team; public- [EMAIL PROTECTED] Subject: Re: responseXML/responseText exceptions and parseError Zhenbin Xu wrote: [Zhenbin Xu] Regardless what different browser does today, rich parsing error is an important feature for developers. I have found it can pinpoint the exact problem that otherwise would have been difficult to identify when I sent incorrectly constructed XML file. And given that the goals is to define a useful spec for future XHR implementations, we should define how rich parser error is surfaced instead of omitting it because nobody but IE supported it. It is even more important we define it in the XHR spec because it is not part of DOM Core. Otherwise such a key piece would be lost and we will have diverging implementations. The goal of XHR Level 1 was to get interoperability on the feature set that exists across the major implementations of XHR today, so I don't think parse error information fits the bill there, but it sounds like a great feature to look into for XHR Level 2. [Zhenbin Xu] Did something happen to your reply here? [Zhenbin Xu] Indeed it would already be very useful if XHR1 is to summarize behaviors of all major implementations today, and document the common behaviors. In which case the spec should try to accommodate all major browsers and leave controversial parts to XHR2. This is why we suggested the null or exception language. So strategy that the spec has been following has been to use the feature set that is common between browsers, but for those features try to define a good useful spec that archives interoperability and a solid API for developers to develop against. The reason we didn't want to write a spec that accomodates all major browsers is that such would be largely useless. When you get into the details browsers behave differently enough that the spec would have to be so fuzzy that it would essentially just be a tutorial, not a specification. Wordings like null or exception is a pain for developers. It's also something that is hard to build future specifications on. Especially when taken to the whole XHR spec. Hope that explains why the spec looks the way it does? / Jonas
