RE: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]
I want to re-emphasize that XDR is targeting cross-domain access of public data only. One can already access those public data on the server anonymously. XDR allows this to be done from within the browser rather than through server side proxy or custom applications. The custom header is simply additional measure to allow server explicitly opt-in. CS-XHR, on the other hand, appears to be trying to handle cross-domain access of private data. I don't know if the private data is meant to be something similar to personal photo album or someone's private bank account information. I would assume they have different security requirements. I don't have a clear picture how banks can utilize CS-XHR to handle their private data. Trying to provide a general solution here is bound to have a lot of pitfalls. I know this may sound a bit vague and doesn't address the questions below. But this is a long conversion and I am not sure if we can sort out all without face to face discussions. So I wanted to get the meta points across and this may be of interest. Thanks! Zhenbin -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2008 10:00 PM To: Sunava Dutta Cc: Arthur Barstow; Marc Silbey; public-webapps; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion Subject: Re: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS] Hi Sunava et Al, Thanks for the feedback! This is a great start for a discussion. I hope we can get to more concrete discussions about the various issues that microsoft is seeing and try to figure out ways to address them. There is a lot of experience at microsoft on these issues, especially as first deployers of the XMLHttpRequest API, so I'm greatly looking forward to using that experience to improve the Access-Control spec. Hopefully we can get to those meaty parts in this discussion that is following from your mail. I'll start with a mini FAQ to avoid repeating myself below: Why is the PEP in the client rather than the server? In order to protect legacy servers some of the enforcement will have to live in the client. We can't expect existing legacy servers to all of a sudden enforce something that they haven't before. In fact, even XDR using client side PEP. It's the client that looks for the XDomainRequest header and denies the webpage access to the data if the header is not there. In fact, Access-Control does allow full PEP on the server if it so chooses by providing an Origin header. Is Access-Control designed with Security by design Yes. In many ways. For example Access-Control does not allow any requests to be sent to the server that aren't already possible today, unless the server explicitly asks to receive them. Additionally Access-Control sets up a safe way to transfer private data. This prevents sites from having to invent their own which risks them inventing something less safe. Thirdly, Access-Control integrates well with the existing HTTP architecture of the web by supporting REST apis and the Content-Type header. This allows existing security infrastructure to inspect and understand Access-Control requests properly. What about DNS rebinding attacks. Even with DNS rebinding attacks Access-Control is designed not to allow any requests which are not possible already in todays web platform as implemented in all major browsers. Especially the last point is something that seems to have been misunderstood at microsoft. It is not the case that DNS rebinding attacks affect Access-Control any different than it affects the rest of the web platform. Any server that wants to protect itself against DNS rebinding attacks in the current web platform will automatically get protected against Access-Control. And any site that does not protect itself is already vulnerable to the exact same attacks with Access-Control as it is on the current web platform. In fact, Access-Control is less vulnerable than XMLHttpRequest on its own is. So a server doesn't need to deploy anything extra to defend itself against Access-Control. Section 4: Secure Design Principles Why Secure Design Principles Are Important__ */Secure by design/*/, in /software engineering http://en.wikipedia.org/wiki/Software_engineering/, means that the software has been designed from the ground up to be secure. Malicious practices are assumed, and care is taken to minimize impact when a security vulnerability is discovered. For instance, when dealing with /user http://en.wikipedia.org/wiki/User_%28computing%29/ input, when the user has to type his or her name, and that name is then used elsewhere in the /program http://en.wikipedia.org/wiki/Computer_program/, care must be taken that when a user enters a blank name, the program does not break
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: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
I think we are now off track. Nonetheless we should realize that customer cannot write an interoperable page with my fictional home grown browser if it doesn't exist or doesn't have the needed feature when the page was written. I doubt customers would write against particular browser if equal efforts can results in interoperable solutions run on top multiple browsers. Now that the solutions are in place, they deserve our consideration. I would argue it is important to think about customer's migration path when we design new feature or standardizing existing ones. Otherwise we would be painting customers into corner and blaming them for their dilemma. -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 9:48 PM 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 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. `._.-(,_..'--(,_..'`- .;.'
RE: New: Tracking Issues in XHR that we raisedRE: Was: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
-Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 7:22 PM To: Zhenbin Xu Cc: Sunava Dutta; Ian Hickson; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: New: Tracking Issues in XHR that we raisedRE: Was: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite Zhenbin Xu wrote: -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 2:38 PM To: Sunava Dutta Cc: Ian Hickson; Zhenbin Xu; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: New: Tracking Issues in XHR that we raisedRE: Was: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite Sunava Dutta wrote: Thanks Ian, Zhenbin for clarifying the issues and a continuing very productive discussion. Meanwhile, I'm summarizing some of our requests for the editor based on issues we've had an opportunity to clarify...There are many conversations going on and I'd hate to see points getting lost and would like the specs/test cases updated for issues where discussions are not ongoing. -Ongoing discussion: Specify the parseError attributes for Document Objects or specify this can be sent out of band. This could be something we don't have to hold the XHR spec back for as long as we make a note in the specification that this is pending. There are people currently talking for and/or against it. Zhenbin is articulating IE's point. Sounds good to me. We have an informative Not in this specification section already, sounds like a good idea to add there. - Throwing exceptions on state violations is easier to understand and we should change the spec to reflect this. (for the sake of a consistent programming model). The spec should have INVALID_STATE_ERR exception (the exact language can be worked out) if a site is expecting an exception and gets a null as this would not work if the developer is trying to write a wrapper object in XHR. I haven't heard any strong objection here or compelling argument against it that's been sustained. I do think there has been some disagreement here. Anne has commented on reasons for returning null rather than throwing an exception, and I think I agree with him. I think the correct cause of action here is to raise an issue in the issue tracker. [Zhenbin Xu] I am not familiar with the process here. How does issue gets resolved when it is in issue tracker? Having it in the issue tracker just makes it easier to track since the issue tracker keeps track of all emails on the subject (if you put ISSUE XX in the subject). We have enough debate already that there is technical merit to throw exception rather than null. It is not going to be productive for us to keep spending time on it. I do agree we have debate, I don't agree we have agreement on that throwing an exception is the right thing to do. The argument for returning null is that it makes for a cleaner API, exceptions should only be thrown in exceptional circumstances. And based on available data it doesn't seem like sites currently care one way or another, so I think we should go for the cleaner API. What is the argument for throwing an exception? / Jonas [Zhenbin Xu] State violations. XHR is designed as a state machine. The whole spec is written centered around states (OPENED, SENT etc.). Remember we are not designing a new object. It is an object invented long time ago and the inventor had decided to pick the exception model. Yes there are complexities surrounding a state machine approach. This is why in our new XDR model, we no longer use the readyState mode. However we cannot retrofit an object that was created almost ten years ago.
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
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Exceptional situation in general doesn't hinder interoperability. It only becomes an issue if it is clearly stated in W3C spec and used as a way to measure if UA is compliant. We have provided our feedback to write spec in a away all current browsers are complaint. If the general sentiment is to pick one model, then lets pick the exception model, which is the model original XHR inventors picked. Technically because all other XHR methods/properties throw exceptions in case of state violation, exception for responseXML/responseText is better. If original XHR picked the null model, then we should go null model. The important thing really is consistency, thus predictability. Thanks! Zhenbin -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2008 2:13 PM 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 Zhenbin Xu wrote: The issue of return null or an exception is simply a compromise here. IE would throw an exception for state violations. Accessing responseXML before open() is a state violation so it would trigger exception. Other browsers may return null in such situation. In order to accommodate all browsers, the spec would have to be rewritten in some way. Please note that it is not a goal for the spec to be written in such a way that all existing browsers are conforming to the spec. It turned out that it was impossible to write a spec with that goal while still keeping the spec useful. So we no longer try to accomodate all browsers, but instead write a spec that leads to interoperability between browsers. We would certainly love to have the spec change to MUST throw INVALID_STATE_ERR exception, which is consistent with other INVALID_STATE_ERR cases. For instance, the spec says if send() is called before OPENED, it should trigger INVALID_STATE_ERR exception. Another example is that user agent must raise INVALID_STATE_ERR if status is not available. responseText and responseXML are the outlier in the spec. Personally I think it makes more sense to return 'null' from .responseXML. We at mozilla have not had any interoperability problems with this behavior. Exceptions are better left for exceptional circumstances. However I can't say that I think the behavior is very important to me one way or another, as long as it's usefully defined. Best Regards, Jonas Sicking
